Port QSystemSemaphore

[Dmitry A. Kuminov]

Provide an OS/2 version of the QSystemSemaphore class.

[Dmitry A. Kuminov]

[QSystemSemaphore ​http://doc.qtsoftware.com/4.5/qsystemsemaphore.html] (as well as QSemaphore) is not the same as event semaphore in OS/2 -- it maintains a resource counter (specified at semaphore creation time) which is decreased every time the semaphore is acquired and increased when it is released. Blocking occurs when the counter goes down to zero, unblocking happens when it goes above zero again.

In fact, we don't have a native primitive for such kind of semaphores in OS/2. It's not a problem in case of QSemaphore where it is implemented using a QMutex, a QWaitCondition and a counter variable, but QSystemSemaphore is a named inter-process resource and we can't simply go that way because QMutex/QWaitCondition aren't inter-porcess.

[Dmitry A. Kuminov]

My bet is that we should use a named event semaphore for waiting and signaling and a named shared memory cell for storing the resource counter. The counter will be increased/decreased using atomic operations so a mutex is not necessary.

[Dmitry A. Kuminov]

Actually, there is a major problem. The important aspect of IPC functionality of the semaphore is that if a process that has acquired a number of resources crashes, this number must be automatically released so that other processes are able to acquire them; breaking this rule means an non-fixable denial of service in case of the crash of one of the involved processes.

While this looks solvable at first sight, the difficult one is a case when starving processes are waiting for a resource to be available and the owning process dies. Obviously, the waiting processes should be unblocked in this case.

The only way to get such unblocking notifications I can think of is to use a native OS/2 mutex per every process that works with QSystemSemaphore. This mutex will be held by the process as long as it owns (has acquired) one or more resources in QSystemSemaphore terms. All waiting processes trying to acquire some resource will wait on a muxwait composed of the mutexes of all involved processes so a crash in any of them will let one of the waiters proceed and handle the crash gracefully (clean up the resources acquired by the crashed process).

The shared memory block will be used to store information about processes and their resource counters. It may make sense to use QSharedMemory for that purpose to avoid double work so QSharedMemory must be ported first.

Anyway, this implementation promises to be non-trivial and requires good testing while QSystemSemaphore doesn't seem to be used by QtCore/QtGui? itself and hence isn't worth the beta version.

Therefore, I'm putting the QT_NO_SYSTEMSEMAPHORE define to configure.cmd and and moving the task to the Qt GA milestone.

[Dmitry A. Kuminov]

Disabled in r70.

[Dmitry A. Kuminov]

I don't know how often this class is used in real applications; there are other old school methods for IPC such as sockets. For this reason, I don't set it as a blocker until we prove that a lot of applications rely on it.

[Silvan Scherrer]

moved to enhanced, as we guess it's not used much

[Silvan Scherrer]

this is done in Qt5. No Qt4 work planned for such enhancements.