1

I am having trouble trying to represent some multithread process and I would appreciate some advice.

Please let me explain this with code. (in C++'ish because that is what I am familiar but consider it just pseudo code- it is easy to understand)

Say I have two classes MainClass.cpp and ElementClass.cpp

the MainClass has as an element an object of ElementClass

class MainClass{

  MainClass:myElement();  // The myElement is constructed when the MainClass is constructed

 method1()
 {
  myElement.method1();
 }

  method2();

  ElementClasss myElement;
}

and

class ElementClass{

   ElementClass():thread_handler(&separateThreadMethod){}

   method1();

   void separateThreadMethod()
   {
     call MainClass method2();
   }
} 

So as you can see when an object of MainClass is constructed , its MyElement is also constructed and it initiates another thread that runs separateThreadMethod.

The MainClass object is kept spinning so its method1 can be called at any time. This also calls myElement.method1()

So as you can see there are two threads. However they both use parts of MainClass and ElementClass.

Now I want to represent this in a Diagram and I am wondering how.

Initially I used Activity Diagrams and I put different partitions for each thread in ElementClass. I also put a different partition for MainClass.

But MainClass has methods that are called by both threads so in the partition for MainClass there is not a clear line of process.

Is there a better way to represent this? Perhaps eliminate representing the classes and just represent the threads?

Any advice will be greatly apreciated

1

It is indeed important to represent this correctly: there is a frequent mental bias when using C++ multithreading for member functions or, worse, constructors that leads to think that the object would run in a thread whereas in reality only code executes within a thread.

The typical representation of a sequence diagram only amplifies this bias: each object is shown on its lifeline, which could then be understood as a thread of execution.

An informal workaround to break this perception is the use of different colors to materialize the execution path corresponding to the different threads. But this seems feasible only for simple diagrams and might quickly lead to ambiguities in regard of the formal UML semantics. Beware of false synchronisation assumptions that might be caused by this interleaved diagramming technique:

enter image description here

A less misleading representation could seem be to show a lifeline per thread, std::thread being the object represented by the lifeline. The problem is that messages are exchanged by objects calling methods of other objects. So, to stay accurate, each thread lifeline would invoke methods from objects materialized by other lifelines. But this would then be as misleading as before.

A more robust and formal way could be the use of a par combined fragment. This would show the parallel things going on, nevertheless keeping the focus on objects. But this might be less convenient to read and understand, especially if the par scetions are lengthy:

enter image description here

A suitable alternative would be to use a diagram that allows to shift focus on the thread of execution. For this, you may consider using an activity diagram. Fork and join nodes allow to present accurately the creation and the joining of the threads. Visually, you may further highlight the multithreading by using activity partition according to the threads. This will be accurate, and not mislead anybody. However the flow approach makes the objets and the exchanges between the objects less visible.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.