Semaphore Bug Confirmed: an update

[K. A. Dahlke]

I have been receiving mail asking:
"What about that semop(2) bug?  Is it really a bug?
Is it fixed, or being fixed?
Is it only UNIX5.0, or does it appear in subsequent releases?"
Here is a brief update.
If you missed the articles on this (a couple months ago),
contact me, and I will send you the test programs.

The bug is a real independently confirmed bug.
The UnIX people know about it, and an MR was issued.
To date, the bug has only appeared on UNIX5.0 machines.
I (and others) have run my programs for hours on UNIX5.2 machines.
This does not "prove" UNIX5.2 semaphores are fine,
since the bug is a non-deterministic statistical thing.
Our machine is going to UNIX5.2 in a couple of weeks,
and I will have a chance to run my program for days,
not just the hours I could snatch from other machines.
I will post news if there is a problem with 5.2 semaphores.
My guess is: semaphores will work fine.

As a side note, some people pointed out some problems with UNIX semaphores.
The scheduling of processes blocked on a semaphore is very unfair.
If four processes consistently block on a semaphore, only two get scheduled.
These two alternate while the other two remain blocked.
This is not a "bug" but it is a questionable implementation of semaphores.
I am not actively investigating this, since it is not a problem
in our application.  We rarely have many processes blocked on one semaphore.
Has the unfair scheduling been a problem for anyone?
-- 

Karl Dahlke    ihnp4!ihnet!eklhad