开发者

Erlang digraph atomicity and isolation guarantees

开发者 https://www.devze.com 2023-02-21 08:19 出处:网络
Are digraph atomicity and isolation guarantees described anywhere? Especially: What state will another process see digraph in, if another 开发者_高级运维process tries to access it (vertices(), out

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?


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号