Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 exptools 1/6/84; site ihnet.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!ihnp4!ihnet!eklhad
From: eklhad@ihnet.UUCP (K. A. Dahlke)
Newsgroups: net.unix-wizards
Subject: Semaphore Bug Confirmed:  an update
Message-ID: <167@ihnet.UUCP>
Date: Thu, 18-Oct-84 10:33:58 EDT
Article-I.D.: ihnet.167
Posted: Thu Oct 18 10:33:58 1984
Date-Received: Sun, 21-Oct-84 09:16:45 EDT
Organization: AT&T Bell Labs, Naperville, IL
Lines: 31

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