views:

875

answers:

6

I'm sitting there every time I model my systems, thinking, there must be a better way to model concurrency than using UML activity diagrams.

Please share your thoughts. What's your favourite tool or format for modelling and getting a clear understanding of how to build a concurrent system?

+3  A: 

the FSP language (Finite State Processes) allows you to model and test concurrent systems. A good book to learn about this from is Concurrency by Jeff Magee

workmad3
I believe we use that book at my university for...hmm...Real-Time Systems, maybe. So it must be good, I figure, but I haven't taken that course yet.
Thomas Owens
A: 

I'm not an expert in modeling multithreaded systems, but I usually do it like this:

  • I see Thread as kind of Workers
  • every Worker returns 1..n results

As input to the Worker I usually have some kind of queue (or a resultset), and the output gets handled asynchronously over Event delegation.

But if I had a situation where I couldn't apply this scheme, I'd be lost somehow :-)

=I'm a SwingWorker guy

Andre Bossard
A: 

I studied Petri nets in school, but have never actually used them in the real world.

Jacob
+3  A: 

Personally, I use activity diagrams to model tasks, parallelism, forks and joins, etc.

For data-oriented aspects state diagrams are more "suitable", but far not perfect.

What type of modeling tool or diagram could be used for synchronization scenarios or deadlock (or livelock) detection would raise my interest too.

Petri nets are great to make simulations in terms of finding bottlenecks...

Michael Damatov
I just come here looking for synch scenarios and lock finding.
SoMoS
+1  A: 

The Wikipedia page on Concurrent programming lists the following models of concurrency with links to their own articles:

  • The Actor model
  • Petri nets
  • Process calculi such as
    • Ambient calculus
    • Calculus of Communicating Systems (CCS)
    • Communicating Sequential Processes (CSP)
    • π-calculus

Anybody used any of them?

Don Kirkby
+2  A: 

Thinking of parallel things as objects using asynchronous message-passing to communicate, and drawing message-sequence charts usually help me get a feeling for the order in which things need to happen to be correct. Note that the actual drawing tool will probably depend on the nature of the parallelism you are looking for:

  • Shared memory or local memory?
  • Distributed or local to a machine?
  • Is it loop-level array-based?
  • Is it async message passing?
  • Is it shared memory?
  • Is it via a database?
  • Is it a streaming data-flow?

Etc. I think the first order is to figure out the overall style of parallelism you have in your app. What makes it suitable to be parallel? What is the property of the domain that can be parallelized over? Different sets of work (GUI + background process, for example), or a steady stream of data (media processing), or ... ? Once that is decided, I think the decomposition style that is most useful will present itself quite naturally.

jakobengblom2