Opened 9 years ago

Closed 3 months ago

#11 closed task (fixed)

Port QSystemSemaphore

Reported by: dmik Owned by:
Priority: major Milestone: Qt 5
Component: QtCore Version: 4.5.1 Beta 1
Severity: low Keywords:
Cc:

Description

Provide an OS/2 version of the QSystemSemaphore class.

Change History (8)

comment:1 Changed 9 years ago by dmik

  • Owner set to dmik
  • Status changed from new to accepted

comment:2 Changed 9 years ago by dmik

[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.

comment:3 Changed 9 years ago by dmik

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.

comment:4 Changed 9 years ago by dmik

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.

comment:5 Changed 9 years ago by dmik

  • Milestone changed from QtCore Beta to Qt GA
  • Owner dmik deleted
  • Status changed from accepted to assigned

Disabled in r70.

comment:6 Changed 9 years ago by dmik

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.

comment:7 Changed 9 years ago by diver

  • Milestone changed from Qt GA to Qt Enhanced
  • Severity set to low

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

comment:8 Changed 3 months ago by diver

  • Milestone changed from Qt Enhanced to Qt 5
  • Resolution set to fixed
  • Status changed from assigned to closed

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

Note: See TracTickets for help on using tickets.