2

Are digraph atomicity and isolation guarantees described anywhere?

Especially:

  1. What state will another process see digraph in, if another process tries to access it (vertices(), out_neighbours() etc) in the middle of del_vertex: before del_vertex, in the middle of del_vertex (i. e. vertex is deleted, edges are not or edges are deleted, vertex is not) or after del_vertex (i. e. another process will be blocked until operation is over)?
  2. The same question regarding del_vertices.

If I understand right, digraph is implemented using 3 ets tables. Is there any additional locking mechanism between them in order results to be consistent?

MSalters
  • 173,980
  • 10
  • 155
  • 350
trytrytry
  • 373
  • 2
  • 6
  • BTW: you have two disjoint accounts one with reputation 11 and this one with reputation 6. You should consider registering if you want to use SO from different computers. – Peer Stritzinger Apr 03 '11 at 18:25

1 Answers1

4

Looking at the source of digraph.erl I can see no extra locking going on.

del_vertex(G, V) ->
    do_del_vertex(V, G).

...

do_del_vertex(V, G) ->
    do_del_nedges(ets:lookup(G#digraph.ntab, {in, V}), G),
    do_del_nedges(ets:lookup(G#digraph.ntab, {out, V}), G),
    ets:delete(G#digraph.vtab, V).

So when you look at the digraph from another process you'll see the following states depending on timing:

  • Everything before the del_vertex/2
  • Some edges to and from the vertex deleted
  • The vertex itself deleted

The same happens vertex after vertex for del_vertices/2.

If you want more atomicity create the digraph protected and wrap it into its own server e.g. a gen_server usually implementing part of the functionality that needs close access to the digraph.

Peer Stritzinger
  • 8,232
  • 2
  • 30
  • 43