I have found that the message-passing paradigm of CSP is much easier
to understand (compared to traditional lock-based threading) and leads
to organizing my code as "active objects". Besides being able to
reason about the operation of the individual SPs, I also like having a
top-level "flow graph" right in the code.
At work I inherited a heavily-threaded codebase that was having
intermittent problems that seemed threading-related. It was pretty
typical multi-threaded, object-oriented code: each class had its own
mutex to protect its internal data structures and the execution
threads would weave in and out of multiple classes. You've seen this
kind of code: every member function first locks a mutex unless it was
called from another member function of the same class. Debugging the
problems proved very difficult and careful code inspection did not
help either. I finally decided to change some of the code to a CSP
style. Unfortunately PyCSP was not feasible for multiple reasons, so
I used the Python Queue class for communicating between my new
sequential threads. Though I only partially switched to the CSP
style, the code became simple enough that I could verify correct
operation of the remaining mutexes by inspection. Testing
demonstrated that the code was solid, and I credit the CSP style with
making the code both solid and understandable.
thanks for the insight.
> I have found that the message-passing paradigm of CSP is much easier
> to understand (compared to traditional lock-based threading) and leads
> to organizing my code as "active objects". Besides being able to
> reason about the operation of the individual SPs, I also like having a
> top-level "flow graph" right in the code.
Then you will like the tracing module including the PlayTrace tool
(requires wxPython, Graphviz).
For sneak peak, look into /branches/TracePyCSP
In CSP, I am especially fond of process isolation and the obvious
dependencies through use of channels.
- Rune