Home > Blockchain >  Modelling inter thread communication in activity diagram
Modelling inter thread communication in activity diagram

Time:01-13

I am trying to model an application which runs multiple concurrent flows. In this situation multiple threads can create events and store them in a buffer which are then collected and displayed by another thread. The receiving thread is supposed to block and wait for incoming events.

I have currently modelled it like this: enter image description here This example uses object flows. However I am not sure if this is the correct way to model this type of inter thread communication.

The other option I was looking at is using signals but I'm not sure about that either. Any help would be appreciated.

CodePudding user response:

Every activity requires all tokens to be offered before it can start. You will have to use a buffer node as a queue.

CodePudding user response:

Object flows capture inter thread communication well.

You could also use signals, if you want to be more specific and your system uses in fact messages.

There is one problem in your diagram though: The Display Event action consumes all offered control tokens and one object token on each invocation. I can‘t tell from your diagram, but probably there is only one control token. That means, the action will only run once. The solution is, to delete the control flow. The action then starts for each incoming object token.

Each output pin acts as a local buffer. If tokens are generated faster than the event can be displayed, tokens will potentially pile up in multiple pins. In this case it is undefined which pin will be the source of the next token. This is not necessarily a problem, but if tokens shall be processed in chronological order, you need to use a central buffer. The symbol is a rectangle with the keyword «central buffer»

  • Related