Abstract: Visualize an architecture of functions with the Shared Tasks graph.
What’s worse than having too many chefs in the kitchen working on the same dish? Thread concurrency problems.
A task – an independent thread of execution – manipulates and uses objects. When another task also reads or writes to the same object simultaneously, it may result in a race condition. I made a graph to help with this problem.
Using the Graph
First, make an architecture automatically with this script or manually in Understand. (Read more about automatically and manually creating architectures.)
Then, right click on the architecture and view the Shared Tasks graph.
Let’s check it out with 3 functions from Fastgrep. I’m viewing 3 functions in regexp.c called regatom, reginsert, and regoptail as my 3 tasks.
Although this is a small single-threaded sample, it includes a lot of call complexity, and even indirect recursion. Three out of the five global objects are shared. Let’s filter the reference arrows on the graph.
Using the graph options, the references selected to be filtered out turn into dashed lines. The function calls are filtered out too. Next, let’s only show the shared objects.
Finally, let’s simplify the graph by hiding the intermediate function calls.
With this graph, it’s okay to have lots of chefs in the kitchen; they will all collaborate together to make something fantastic.
