Date: Wed, 18 Sep 2002 19:45:10 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Alfred Perlstein <alfred@FreeBSD.org> Cc: Daniel Eischen <eischen@pcnet1.pcnet.com>, hackers@FreeBSD.org, deischen@FreeBSD.org, Garrett Wollman <wollman@lcs.mit.edu> Subject: Re: sem_init help? Message-ID: <3D893A36.88EA3C13@mindspring.com> References: <20020919005959.GO86737@elvis.mu.org> <Pine.GSO.4.10.10209182104060.27827-100000@pcnet1.pcnet.com> <20020919015911.GQ86737@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > now here's the problem, one can basically stick a sem_t into a shared > memory location, then one can share it amongst processes (provided > pshared was set). However there's no requirement that these other > processes do any form of "open" on the sem_t, hence I really have no > way of tracking its usage other than by: > > a) auto-terminating it when the process that did sem_init exits. > b) tracking the page where the actual sem_t was created until either > it is reclaimed via sem_destroy or the page is free'd back to the > OS. > > Unless I'm missing something here. You're safe, but it's not something I would recommend. I thing that sem_t is supposed to be an opaque type (e.g. it could even contain a pointer to a kernel address, after sem_init()). But a strict interpretation would let you get away with not tracking it, if it's in shared memory that's tracked (either by the process, in an mmap(), or by the system, in a System V shared memory segment). Here is the relevent text from sem_destroy(): The sem_destroy() function is used to destroy the unnamed semaphore indicated by sem. Only a semaphore that was created using sem_init() may be destroyed using sem_destroy(); the effect of calling sem_destroy() with a named semaphore is undefined. The effect of subsequent use of the semaphore sem is undefined until sem is re-initialised by another call to sem_init(). I take this "undefined" to mean: "You can implement it so that subsequent accesses are successful, but doing so engourages people to write code that depends on this behaviour, and breaks on implementations where it's not true." IMO, this is the same type of thing that got threads programmers to assume "all threads are processes because Linux threads are effectively processes", and make the design mistakes in their code (the Netscape GIF rendering engine, now corrected, and the recently discussed on -current other code which shall remain nameless, which has not yet been corrected). Encouraging that would be Bad(tm). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D893A36.88EA3C13>