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