Best way to describe a threaded application ? (diagrams)
-
I'm trying to design a threaded application. What would be the best way to graphically represent the different worker threads interaction in regards to synchronization (to/from the main application thread) ? I was thinking of something like a UML sequence diagram. Is there something better ? Thanks.
Nihil obstat
It was broke, so I fixed it.
-
It was broke, so I fixed it.
Fuzzy spaghetti ? :rolleyes:
Nihil obstat
-
I'm trying to design a threaded application. What would be the best way to graphically represent the different worker threads interaction in regards to synchronization (to/from the main application thread) ? I was thinking of something like a UML sequence diagram. Is there something better ? Thanks.
Nihil obstat
Using a needle?
Gryphons Are Awesome! Gryphons Are Awesome!
-
I'm trying to design a threaded application. What would be the best way to graphically represent the different worker threads interaction in regards to synchronization (to/from the main application thread) ? I was thinking of something like a UML sequence diagram. Is there something better ? Thanks.
Nihil obstat
There's a useful UML diagram, not sequence, but I'm not in the mood to look it up. I'll try to remember to look tomorrow and get back to you.
Reality is an illusion caused by a lack of alcohol
-
There's a useful UML diagram, not sequence, but I'm not in the mood to look it up. I'll try to remember to look tomorrow and get back to you.
Reality is an illusion caused by a lack of alcohol
"Not in the mood?! Mood's a thing for cattle and love play, not looking"
Nihil obstat
-
"Not in the mood?! Mood's a thing for cattle and love play, not looking"
Nihil obstat
Do you want the elephant diagram or not?
Reality is an illusion caused by a lack of alcohol
-
Do you want the elephant diagram or not?
Reality is an illusion caused by a lack of alcohol
Yeah, that would be dandy. :-)
Nihil obstat
-
There's a useful UML diagram, not sequence, but I'm not in the mood to look it up. I'll try to remember to look tomorrow and get back to you.
Reality is an illusion caused by a lack of alcohol
Nagy Vilmos wrote:
There's a useful UML diagram, not sequence
more from me | GALex: C++ Library for Advanced Genetic Algorithms
-
Fuzzy spaghetti ? :rolleyes:
Nihil obstat
Maximilien wrote:
Fuzzy spaghetti ?
No, threads, made with fuzzy logic! :-D
It was broke, so I fixed it.
-
I'm trying to design a threaded application. What would be the best way to graphically represent the different worker threads interaction in regards to synchronization (to/from the main application thread) ? I was thinking of something like a UML sequence diagram. Is there something better ? Thanks.
Nihil obstat
-
I'm trying to design a threaded application. What would be the best way to graphically represent the different worker threads interaction in regards to synchronization (to/from the main application thread) ? I was thinking of something like a UML sequence diagram. Is there something better ? Thanks.
Nihil obstat
Try playing around with Windows Workflow Foundation designer. To me it represents several types of parallel tasks quite nicely.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
I'm trying to design a threaded application. What would be the best way to graphically represent the different worker threads interaction in regards to synchronization (to/from the main application thread) ? I was thinking of something like a UML sequence diagram. Is there something better ? Thanks.
Nihil obstat
Here's a recent an example of a sorta sequence diagram that I created in Visio in order to illustrate two threads : http://imm.io/19d1N[^] Hope it helps ...
-
I'm trying to design a threaded application. What would be the best way to graphically represent the different worker threads interaction in regards to synchronization (to/from the main application thread) ? I was thinking of something like a UML sequence diagram. Is there something better ? Thanks.
Nihil obstat
Well, sequence diagrams as a part of your overall documentation set are fine, but with anything operating over multiple threads in a modern microcomputerarchitecture where threads can be allocated individual cores, what I think you are looking for is something a little more focussed. If you are using your program (User threading) alone to control threading within a single process, then I would develop a set of livelock and deadlock scenarios which could occur within your process using some kind of state diagram/table. Deadlock in particular is easily avoided with well formed state transitions when you are using non-cpu based threads (All IO is effectively synchronous and the threading is in fact just time-splicing rather than anything else). When using true threads outside of the control of your own code, then consider either: a:) Wrapping a thread controller class around your running threads. The controller has a forward running check which can effectively interrupt a thread if no forward progress is being made on a thread. With this option, class, sequence and interaction diagrams along with state diagrams suffice, paying attention to the new class/(es), but it is necessary to make sure that this thread itself is not locked. If possible fork it into a new process space, possibly with new affinity. This will also alter your exception heirarchy and will require thought as to how to deal with refusals or returns by the thread controller. (Highly recommended in complex scenarios, particularly with high, precise I/O required, but where loss is acceptable (Computer games, etc)) b:) Isolate the most likely blocking activity and thread out these activities in a class/(es) which allows buffering and non blocking messaging into the class. This can be done in a loss-less manner, but can be slow. Again, the class, sequence and interaction diagrams along with state diagrams are all that are required for this mechanism. All of these are standard diagrams and can easily be done in Visio, but the most most important thing is to understand what your threads are doing, and to anticipate the exception scenarios. In particular, if you are considering terminating a thread from a controller, then be wary of leaving library state changed, or heap memory un-released. Good luck with your endeavours anyway.
-
Nagy Vilmos wrote:
There's a useful UML diagram, not sequence
more from me | GALex: C++ Library for Advanced Genetic Algorithms
I agree. I read martin Fowler's UML distilled a while ago and activity diagrams are suitable for showing multiple threads. You can branch off and join up again. They look like flowcharts. I think that's the closest UML one for what you want
-
I agree. I read martin Fowler's UML distilled a while ago and activity diagrams are suitable for showing multiple threads. You can branch off and join up again. They look like flowcharts. I think that's the closest UML one for what you want
I have a good book called "Doing Hard Time" by Bruce Powel Douglass - he uses quite a few different types of UML diagrams, but I think Chapter 8 on "Architectural Design" is most relevant here. The Concurrent Sequence Diagram on p378 is also known as a swim lane diagram; he then shows the same (robot -based) example as a Concurrent Collaboration Diagram and a Concurrent Timing Diagram. He also describes a lot of real-time patterns like watchdogs and monitor-actuators. He provides a swim-lane representation of each pattern.
