From nobody  Wed Oct  7 23:34:56 1998
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id XAA03264;
          Wed, 7 Oct 1998 23:34:56 -0700 (PDT)
          (envelope-from nobody)
Message-Id: <199810080634.XAA03264@hub.freebsd.org>
Date: Wed, 7 Oct 1998 23:34:56 -0700 (PDT)
From: rrs@lmi.net
To: freebsd-gnats-submit@freebsd.org
Subject: semop() is not wrapped for thread safety in libc_r
X-Send-Pr-Version: www-1.0

>Number:         8202
>Category:       misc
>Synopsis:       semop() is not wrapped for thread safety in libc_r
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Wed Oct  7 23:40:00 PDT 1998
>Closed-Date:    Mon Jan 3 17:09:39 PST 2000
>Last-Modified:  Mon Jan  3 17:14:52 PST 2000
>Originator:     Rob Schulhof
>Release:        FreeBSD 3.0-19980930
>Organization:
LanMinds Internet
>Environment:
FreeBSD schoolie.lmi.net 3.0-BETA FreeBSD 3.0-BETA #8: Wed Sep 30 20:33:07 PDT 1998
root@schoolie.lanminds.com:/usr/src/src/sys/compile/SCHOOL  i386 
>Description:
Semaphore operations are not thread safe.   If one thread sleeps waiting
on a semop() then all of the threads are suspended.
>How-To-Repeat:
Create a set of threads that wait on a single
semaphore value to reach zero,  increment the value for a finite time,
then decrement the value and exit.

       
>Fix:
Implement semop and semctl wrappers in libc_r.  I don't know if any
kernel mods are necessary.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: jasone 
State-Changed-When: Mon Jan 3 17:09:39 PST 2000 
State-Changed-Why:  
semop() and semctl() do in fact work with libc_r, but they do potentially 
block the entire process.  This is a performance issue to be sure, but 
the only way to "fix" the problem is to poll.  Since the combined use of 
SYSV semaphores and pthreads is of questionable value, and there is no 
elegant "fix", and and since this isn't exactly a bug, I'm closing this PR.
>Unformatted:
