Solid Fluid System Solutions  
Home Software About Hardware Firmware
Folder Icon MemMgr
 
Our ANSI style memory management module.

Document Icon VCore (Library)
Document Icon Memory Manager
Document Icon Run-time Type
Document Icon Object Creation
Document Icon Constructor / Destructor
Document Icon Error Handling
Document Icon Verification
Document Icon Serialisation
Current Document Icon Synchronisation
Document Icon Thread Completion

Synchronisation

Synchronisation is a critical concept for multithreaded applications.

Synchronisation ensures that mutually sensitive resources cannot be accessed in error. Such resources are mutual when two or more threads may access them directly by means of a function call. Typically these resources are class member variables, although it includes global variables also. They may be accessed in error where a function looks at such a resource, makes a decision, and updates the resource on the basis of the decision.

A circumstance could occur where two concurrent threads attempt to call that function at the same time. Without synchronisation it is not possible to ensure that either thread can update the resource correctly on the basis of the data it read. This occurs where one thread reads the resource immediately before the other thread updates it. The second update is based upon stale data.

Synchronisation avoids this problem by means of waitable objects. There are a variety of waitable objects, but Mutex is the simplest and most used. A mutex has one token, and it may hand the token out to a calling thread, allowing it to continue execution. Alternatively it may put the thread into a lightweight blocking loop, in the case where the token has already been handed out. Typically the loop can be thought of as a tight while loop {while(!Token);} but in practice it's actually a task switch, so it's a while loop that consumes no CPU cycles.

Using synchronisation, the first thread gains the token, and the next thread does not so it must wait. Once the first thread has updated the resource it gives up it's token, and the second thread begins to execute again. When it does, it reads the resource as it has been updated by the first thread and the second thread update is not then based on stale data.

Waitable objects like mutex are provided by the operating system, because they must take into account problems which are simply not visible to the application programmer. Waitable objects are handle based, and so it is wise not to let them leak. Implementation of synchronisation in VObject avoids leaks of these kinds. Each VObject may support a mutex by making a single function call to VObject, SetMutable(). Any VObject cleans all it's handles when it is destroyed, in our case it is mutex leakproof.

In addition, VObject provides two functions that simplify the procedure of making an object mutable. Entry() and Exit() are simple void functions that can be called at entry and exit of any object method, to make that method thread safe. In conjunction with the waitable objects, these functions allow re-entrant calls to the class, so there is no worry about deadlock, unless of course there is a flaw in the calling code. Most signifiantly, these functions know if the class has been declared mutable, and are able to decide if they should test for the mutex token. This feature enables a newly programmed object to allow it's user to implement thread safety or not, as they choose. Without this facility, the object would decide it's own mutablity, and this can be very inconvenient in some situations.

Copyright © Solid Fluid 2007-2022
Last modified: SolFlu  Sat, 13 Jun 2009 02:00:51 GMT