intro and CSP war story :)

10 views
Skip to first unread message

Rob

unread,
Mar 15, 2010, 12:04:55 AM3/15/10
to pycsp
I posted on the wiki that I've enjoyed using PyCSP. It is my first
exposure to CSP and since I have primarily used Python in the last few
years, I haven't tried other CSP libraries; however, I did download
the source to a C++ CSP library to try and further understand what
some other implementations were doing so that I could play around with
buffered channels in PyCSP.

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.

Rune M. Friborg

unread,
Mar 15, 2010, 10:03:16 AM3/15/10
to pycsp
Hi Rob,

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

Reply all
Reply to author
Forward
0 new messages