Previous: , Up: ‘blocking' behaviour in runtime context   [Contents]


5.3.2 Implications of ‘blocking’ for Dezyne applications

Obviously, a big concern regarding whether you can use ‘blocking’ in your Dezyne models is that your foreign code running on the main thread must not suffer from being blocked. The Sensor polling implementation could just as easily have been handled in the event loop instead of through dzn::pump; however, then the debouncing algorithm could suffer from not polling consistently. The current event loop only handles the entering of passwords; this is so trivial that blockage is not a concern. However, when more execution takes place on the main thread you will have to make sure that it is allowed to be postponed until the blocking call returns.

A second concern is that the execution semantics of your platform of choice must support some way to schedule events outside of normal main thread activity. If the main thread is blocked and the private Dezyne thread is waiting for events in dzn::pump, the only way to continue is to have some sort of activity outside of the two existing threads. This activity can then release the Dezyne private thread, which can release the main thread again. Examples of such activity are Interrupt Service Routines (ISRs) or raising a signal like in the foreign Timer implementation.

Another consideration you should make is whether the asynchronous process you’re simplifying with ‘blocking’ even benefits from it. RobustTimer could be simplified even more by having a ‘blocking’ start event that returns upon timeout. This would make the components requiring ITimer even simpler, perhaps, but it would no longer be possible to cancel the timer.

In a way, we even removed functionality from Controller by synchronizing the cancellation process; at the end of the ‘external’ chapter, we implemented a “queue” to allow passwords entered during the cancellation to be stored and handled when the process ends. By hiding this process from Controller, such interactions are no longer necessary. Sometimes you can make clever use of the asynchronous period and if that is the case, you will have to consider whether the simplified models outweigh the clever usage.

All in all, there are some hard and some soft constraints to using the ‘blocking’ keyword: hard constraints are the execution model on your main thread and whether it can handle being blocked for an arbitrary amount of time; soft constraints mostly consist of design decisions and whether you can make use of the asynchronous process or not.


Previous: , Up: ‘blocking' behaviour in runtime context   [Contents]