Identify 'nop's and improve their dependencies

[aronisstav]

Inspired by Delivering identical messages VS writing identical tuples in an ETS table.

It might be possible to handle operations that are equivalent to 'nop's ('no operation', e.g. writing the same tuple in an ETS table, linking again to the same process) in a better way, dependency-wise. In the image above, "Interleaving 2" is not interesting (as the second ets:insert for y is a nop), but as explained here we need to keep the dependency with the ets:lookup to correctly reverse the read with the original read.

Perhaps this is more generally possible: 'nop's need not be reversed with ops that depend on their result, but should still happen-before such operations when they race with operations that are not nops.

Source for the graph:

-module(foo).

-export([test/0]).

-concuerror_options([{ignore_error, deadlock}]).

test() ->
  table = ets:new(table, [named_table, public]),
  ets:insert(table, {x, 0}),
  ets:insert(table, {y, 0}) ,
  Fun1 =
    fun() ->
        ets:insert(table, {x, 1}),
        ets:insert(table, {y, 1})
    end,
  Fun2 =
    fun() ->
        ets:insert(table, {y, 1})
    end,
  Fun3 =
    fun() ->
        case ets:lookup_element(table, y, 2) of
          0 -> ok;
          1 ->
            1 = ets:lookup_element(table, x, 2)
        end
    end,
  spawn(Fun1),
  spawn(Fun2),
  spawn(Fun3),
  receive after infinity -> ok end.

[aronisstav]

Migrated to aronisstav#26.