The parameters initialValue and mode are used according to the following rules, which are system dependent. Requests a system semaphore for the specified key. Member Function Documentation QSystemSemaphore:: QSystemSemaphore(const QString & key, int initialValue = 0, QSystemSemaphore::AccessMode mode = Open) Thus if the process acquires a resource and then exits without releasing it, Unix will release that resource.Īpple platforms: Sandboxed applications (including apps shipped through the Apple App Store) require the key to be in the form /, as documented here and here, and the key length is limited to 30 characters. When a process using QSystemSemaphore terminates for any reason, Unix automatically reverses the effect of all acquire operations that were not released.
To protect against this, the first process to create a semaphore for a particular key (usually a server), must pass its access mode as Create, which will force Unix to reset the resource count in the underlying system semaphore. In that case, if the QSystemSemaphore constructor has specified its access mode as Open, its initial resource count will not be reset to the one provided but remain set to the value it received in the crashed process. A subsequent process that constructs a QSystemSemaphore with the same key will then be given the existing system semaphore. If the last process crashes without running the QSystemSemaphore destructor, Unix does not automatically remove the underlying system semaphore, and the semaphore survives the crash. This means that the last process having an instance of QSystemSemaphore for a particular key must remove the underlying system semaphore in its destructor. QSystemSemaphore owns the underlying system semaphore in Unix systems.
This means that when all instances of QSystemSemaphore for a particular key have been destroyed, either by having their destructors called, or because one or more processes crash, Windows removes the underlying system semaphore. Windows: QSystemSemaphore does not own its underlying system semaphore. When using this class, be aware of the following platform differences: release( 2) // resources available = 3Ī typical application of system semaphores is for controlling access to a circular buffer shared by a producer process and a consumer processes. QSystemSemaphore sem( "market", 3, QSystemSemaphore ::Create) The function can also be called with a parameter n > 1, which releases n resources.Ī system semaphore is created with a string key that other processes can use to use the same semaphore. Release() releases one resource so it can be acquired by another process.
Then the resource is acquired and the call returns. If there isn't a resource available, the call blocks until a resource becomes available. Semaphores support two fundamental operations, acquire() and release():Īcquire() tries to acquire one resource.
This means QSystemSemaphore is a much heavier class, so if your application doesn't need to access your semaphores across multiple processes, you will probably want to use QSemaphore. Unlike QSemaphore, a QSystemSemaphore can also be accessed from multiple processes.
Like its lighter counterpart QSemaphore, a QSystemSemaphore can be accessed from multiple threads. Typically, a semaphore is used to protect a certain number of identical resources. While a mutex can be locked only once, a semaphore can be acquired multiple times. A semaphore is a generalization of a mutex.