concurency and synchronisation patterns n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Concurency and synchronisation patterns PowerPoint Presentation
Download Presentation
Concurency and synchronisation patterns

Loading in 2 Seconds...

play fullscreen
1 / 30

Concurency and synchronisation patterns - PowerPoint PPT Presentation


  • 92 Views
  • Uploaded on

Concurency and synchronisation patterns. based on Pattern-Oriented Software Architecture, Patterns for Concurrent and Networked Objects, Volume 2 by Douglas Schmidt, Michael Stal , Hans Rohnert and Frank Buschmann. Design Pattern.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Concurency and synchronisation patterns' - istas


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
concurency and synchronisation patterns

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

design pattern
Design Pattern
  • A design pattern is a general reusable solution to a commonly occurring problem in software design.
agenda
Agenda
  • Synchronisation patterns
    • Scoped Locking
    • Strategized Locking
    • Thread-Safe Interface
  • Concurency patterns
    • Active Object
    • Leader/Followers
scoped locking
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.

scoped locking implementation
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 &);

};

scoped locking explicit accessors
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_;

};

scoped locking example
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_;

};

scoped locking consequences
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
strategized locking
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;

};

strategized locking example
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_;

};

scoped locking example1
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_;

};

strategized locking example1
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;};

};

scoped locking example2
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_;

};

strategized locking example2
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;

strategized locking consequences
StrategizedLocking - Consequences
  • Benefits
    • Enhanced flexibility and customization.
    • Decreased maintenance effort for components.
    • Improved reuse.
  • Liabilities
    • Obtrusive locking.
    • Over-engineering.
thread safe interface
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.

thread safe interface example
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 &) {}

consequences
Consequences
  • Benefits
    • Increased robustness.
    • Enhanced performance.
    • Simplification of software.
  • Liabilities
    • Additional indirection and extra methods.
    • Potential deadlock.
    • Potential for misuse.
    • Potential overhead.
active object
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.

active object1
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
consequences1
Consequences
  • Benefits
    • Enhance application concurrency and simplify synchronizationcomplexity,
    • Transparentlyleverageavailableparallelism,
    • Method execution order can differ from method invocationorder
  • Liabilities
    • Performance overhead.
    • Complicated debugging.
leader followers
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.

leader followers1
Leader/Followers
  • Efficient demultiplexing of I/O handles and threads,
  • Minimize concurrency-related overhead,
  • Prevent race conditions
consequences2
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.