[CGraph] Is the library threadsafe for readonly access?

[chtenb]

It is stated in the CGraph manual that the library is not threadsafe. To what extent is this true?

Suppose a graph structure has been created. If then multiple threads are accessing this graph, but without making any modifications to the graph, would this give any problems?

[magneticnorth]

On Sep 18, 2017, at 6:13 AM, Chiel ten Brinke ***@***.***> wrote: It is stated in the CGraph manual that the library is not threadsafe. To what extent is this true? Suppose a graph structure has been created. If then multiple threads are accessing this graph, but without making any modifications to the graph, would this give any problems?

Good question. Because cdt (the splay tree dictionary) rearranges the tree during search (find) operations, you can’t say it’s threadsafe. I don’t see any comments about this in the code. We really rely on libcdt both for its performance and its feature set, e.g. the ability to nest dictionaries, low cost per dictionary (collection) because we basically create two sets per individual edge per subgraph in graphviz, etc. There are other ways to do this of course (the first libgraph simply had an edge set per subgraph) but it would be a pain to rip up and rewrite that code. There is a lot of work that could be done on graphviz, for example to improve its performance on multicore processors, to bring its set of features up to date, implement some interesting algorithms published in the last few years. A friend suggested recently we try to pass the hat with successful companies or tech industry execs we may know to support work on graphviz, but I’m not familiar with doing that and can’t afford to spend months of time learning how.

[chtenb]

That's a clear answer.

Is the library thread-safe if different threads only access their own graph? What if the same graphviz-context object is used across the threads for laying out the graphs?

[emden]

The problems are much more extensive. For example, many functions rely on static global or local variables, starting with the lexer and parser, including many of the layout phases and utility algorithms, and through output. To be safe, access to all of these would need to be protected by a lock or converted into explicit state data handed to the functions as an argument.

Interestingly, most of the libraries we borrowed from ast (cdt, sfio, vmalloc, etc.) are written so that they can be used in a thread-safe manner.

[magneticnorth]

cdt is threadsafe? that could be quite useful. i believe there may be options to make bison and flex output threadsafe (eliminate global variables). we would have to scrutinize the cgraph pretty closely to figure out where locks are needed. have sometimes wished our solvers could use multicore processors.

…

On Sep 18, 2017, at 4:00 PM, emden ***@***.***> wrote: The problems are much more extensive. For example, many functions rely on static global or local variables, starting with the lexer and parser, including many of the layout phases and utility algorithms, and through output. To be safe, access to all of these would need to be protected by a lock or converted into explicit state data handed to the functions as an argument. Interestingly, most of the libraries we borrowed from ast (cdt, sfio, vmalloc, etc.) are written so that they can be used in a thread-safe manner. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1282 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACtWz4i0T0TVEmMBi9M5J0RW3jYVzEyxks5sjsvogaJpZM4PasHN>.