Synchronization objects

This addition to newObjects ActiveX Pack1 enables scripting and other COM environments to use COM objects packing the OS synchronization features such as Event, Mutex and Semaphore objects. All the objects are free-threaded only (no other models make sense for this kind of functionality).

Although these are very simple COM classes they may have crucial role for multithreaded applications and mixed applications that use directly Win32 API in some parts and use scripting in other parts. Using the COM objects from this section will enable such application to share the synchronization objects between its binary (for example written in C++) parts and its scripting parts.

We strongly recommend reading the synchronization chapters in MSDN before using these objects!

The synchronization objects list:

COMSleeper

Threading model: Free
ProgramID: newObjects.utilctls.COMSleeper
ClassID: {8C086E2F-6CA1-40B2-9A4F-536F321E4A90}

Event

Threading model: Free
ProgramID: newObjects.utilctls.Event
ClassID: {ECC09A75-FB45-4705-8E14-56F5EA5525A5}

Mutex

Threading model: Free
ProgramID: newObjects.utilctls.Mutex
ClassID: {179541F1-D961-4C9B-80E2-58E234A6E389}

Semaphore

Threading model: Free
ProgramID: newObjects.utilctls.Semaphore
ClassID: {385F4698-5A17-4FC9-83E6-AEEABE9AF675}

Notes

The synchronization objects (except COMSleeper) share a common parameter (see the Create members of all the objects) - name. This parameter is by default empty and leads to creation of unnamed objects that can be used only within the same process only (in any thread). If a name is specified a system wide usage is possible. In such case the Create methods will behave this way:

If an object of the same type with the specified name already exist in the system it will be referred by the COM object just initialized. The remaining parameters of the Create method are ignored.

If no such object is found a new is created.

If an object of the same type exists in the system but it is created with security settings that do not allow the current thread to access it the method will fail with "Operation failed" error.

The synchronization objects implement different ways for synchronization over a shared resources. This means that if you have multiple threads or even multiple processes that must share access to critical resources you can use one or more appropriate objects from this set to synchronize the access to them. Most often the synchronization techniques involve sequential access requirements - i.e. one thread at a time should be allowed to perform a particular operation over a specific resource. In these cases the Event and Mutex objects are good for the task. They allow you a guaranteed way to control which thread will be permitted to proceed. The wait methods succeed in only one of them while the rest will wait until the thread that has completed successfully the wait operation releases/sets the object so that another thread can proceed. In many cases Event and Mutex can be used for the same purposes, but the Semaphore object is something much different. It can be configured to allow certain number of Wait operations to succeed (see the count parameter in its Create method). So, it is good when you need to perform some limited number of threads to proceed - e.g. limit the maximum number of concurrent threads doing something. This is particularly good for thread pools, network servers and other applications with threads that involve considerable amount of system or specific resources usage for their work. In such cases a sensible limit should be established and the Semaphore object allows you to do so. Of course, you will be right to guess that most often an application that uses semaphores also needs Events or Mutexes in some parts. For example assume a WEB server with a certain thread count limit. There is still possibility that that more than one threads in it will attempt to access certain file or files requiring exclusive access to it - here an Event or a Mutex may be of use.