Concurency and synchronisation patterns

1. Concurency and synchronisationpatterns based on Pattern-Oriented Software Architecture, Patterns for Concurrent andNetworked Objects, Volume 2 by Douglas Schmidt, Michael Stal, Hans Rohnertand Frank Buschmann

2. Design Pattern • A design pattern is a general reusable solution to a commonly occurring problem in software design.

3. Agenda • Synchronisation patterns • Scoped Locking • Strategized Locking • Thread-Safe Interface • Concurency patterns • Active Object • Leader/Followers

4. Scoped Locking The Scoped Locking C++ idiom ensures that a lock is acquired when control enters a scopeand released automatically when control leaves the scope, regardless of the return path fromthe scope.

5. Scoped Locking - Implementation class Thread_Mutex_Guard { public: Thread_Mutex_Guard(Thread_Mutex &lock): lock_ (&lock), owner_ (false) { lock_->acquire (); owner_ = true; } ~Thread_Mutex_Guard () { if (owner_) lock_->release (); } private: Thread_Mutex*lock_; boolowner_; Thread_Mutex_Guard(const Thread_Mutex_Guard&); void operator= (const Thread_Mutex_Guard &); };

6. Scoped Locking – Explicit Accessors class Thread_Mutex_Guard { public: Thread_Mutex_Guard (Thread_Mutex &lock): lock_ (&lock), owner_ (false) { acquire (); } ~Thread_Mutex_Guard () { release (); } void acquire () { lock_->acquire (); owner_ = true; } void release () { if (owner_) { owner_ = false; lock_->release (); } } private: Thread_Mutex *lock_; bool owner_; };

7. Scoped Locking – Example class Test { public: void test_function_1 { Thread_Mutex_Guardquard(&lock_); //do something } void test_function_2 { Thread_Mutex_Guardquard(&lock_); //do something } private: Thread_Mutexlock_; };

8. Scoped Locking - Consequences • Benefits • Increased robustness • Liabilities • Potential for deadlock when used recursively. • Limitations with language-specific semantics. Thread_Mutex_Guardguard (&lock_); Table_Entry*entry = lookup_or_create (path); if (entry == 0) pthread_cancel(pthread_self()); • Excessive compiler warnings

9. Strategized Locking Similar to Scoped Locking but pass template or polymorphic lock object to the guard constructor. class Lock { public: virtual void acquire () = 0; virtual void release () = 0; };

10. Strategized Locking - Example class Lock { public: virtual void acquire () = 0; virtual void release () = 0; }; class Thread_Mutex_Lock : public Lock { public: virtual void acquire () { lock_.acquire (); } virtual void release () { lock_.release (); } private: Thread_Mutex lock_; };

11. Scoped Locking – Example class Test { public: void test_function_1 { Thread_Mutex_Guardquard(&lock_); //do something } void test_function_2 { Thread_Mutex_Guardquard(&lock_); //do something } private: Thread_Mutexlock_; };

12. Strategized Locking - Example template <typename T>class quard_t { private: boollocked; T& protector; guard_t(const guard_t& orig); public: guard_t(T& _protector) : protector(_protector), locked(false) { protector.acquire(); } virtual ~guard_t() { if (locked) protector.release(); } void release() { if (locke) { protector.release();locked = false;} }; void acquire() {protector.acquire();locked = true;}; };

13. Scoped Locking – Example class Test { public: void test_function_1 { quard<Thread_Mutex>quard(&lock_); //do something } void test_function_2 { quard<Thread_Mutex>quard(&lock_); //do something } private: Thread_Mutexlock_; };

14. Strategized Locking - Example typedef File_Cache<Null_Mutex> Content_Cache; typedef File_Cache<Thread_Mutex> Content_Cache; typedef File_Cache<RW_Lock> Content_Cache; typedef File_Cache<Semaphore_Lock> Content_Cache;

15. StrategizedLocking - Consequences • Benefits • Enhanced flexibility and customization. • Decreased maintenance effort for components. • Improved reuse. • Liabilities • Obtrusive locking. • Over-engineering.

16. Thread-SafeInterface The Thread-Safe Interface design pattern minimizes locking overhead and ensures thatintra-component method calls do not incur 'self-deadlock' by trying to reacquire a lock that isheld by the component already.

17. Thread-Safe Interface Example template <class LOCK> class File_Cache { public: const void *lookup (const string &path) const{ Guard<LOCK> guard (lock_); return lookup_i (path); } void insert (const string &path) { Guard<LOCK> guard (lock_); insert_i(path); } private: mutable LOCK lock_; const void *lookup_i (const string &path)const { const void *file_pointer = check_cache_i(path); if (file_pointer == 0) { insert_i(path); file_pointer= check_cache_i (path); } return file_pointer; } const void *check_cache_i (const string &)const {} void insert_i (const string &) {}

18. Consequences • Benefits • Increased robustness. • Enhanced performance. • Simplification of software. • Liabilities • Additional indirection and extra methods. • Potential deadlock. • Potential for misuse. • Potential overhead.

19. ActiveObject The Active Object design pattern decouples method execution from method invocation toenhance concurrency and simplify synchronized access to objects that reside in their ownthreads of control.

20. Active Object • Methods invoked on an object concurrently should notblock the entire process, • Synchronized access to shared objects should be simple, • Applications should be designed to transparentlyleverage the parallelism available on a hardware/software platform

21. Active Object

22. Active Object

23. Consequences • Benefits • Enhance application concurrency and simplify synchronizationcomplexity, • Transparentlyleverageavailableparallelism, • Method execution order can differ from method invocationorder • Liabilities • Performance overhead. • Complicated debugging.

24. Leader/Followers The Leader/Followers design pattern provides a concurrencymodel where multiple threads can efficiently demultiplexevents and dispatch event handlers that process I/O handlesshared by the threads.

25. Leader/Followers • Efficient demultiplexing of I/O handles and threads, • Minimize concurrency-related overhead, • Prevent race conditions

26. Leader/Followers

27. Leader/Followers

28. Leader/Followers

29. Leader/Followers

30. Consequences • Benefits • Performance enhancements. • It enhances CPU cache affinity and eliminates unboundallocation and data buffer sharing between threads, • Itminimizes locking overhead by not exchanging data betweenthreads, • It can minimize priority inversion because no extraqueuing is introduced in the server, • It does not require a context switch to handle each event • Programming simplicity. • Liabilities • Implementation complexity. • Lack of flexibility. • Network I/O bottlenecks.