Date: Mon, 1 Jun 2009 18:19:03 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Vlad Galu <dudu@dudu.ro> Cc: freebsd-stable@freebsd.org Subject: Re: Unnamed POSIX shared semaphores Message-ID: <20090601161903.GA40377@stack.nl> In-Reply-To: <ad79ad6b0906010833y20042080td1ebe0d3bfffbdc5@mail.gmail.com> References: <ad79ad6b0906010833y20042080td1ebe0d3bfffbdc5@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 01, 2009 at 06:33:42PM +0300, Vlad Galu wrote:
> According to sem_init(3), we can't have shared unnamed semaphores.
> However, the following code snippet seems to work just fine:
> -- cut here --
> sem_t semaphore;
> if (sem_init(&semaphore, 1, 10) < 0)
> std::cout << "Couldn't init semaphore: " <<
> strerror(errno) << std::endl;
> if (sem_wait(&semaphore) < 0)
> std::cout << "Couldn't decrement semaphore: " <<
> strerror(errno) << std::endl;
> int val;
> sem_getvalue(&semaphore, &val);
> std::cout << "Value is " << val << std::endl;
> -- and here --
> Is this a case where sem_init() silently reports success, or should be
> the man page get an update?
Reading the code, it seems like this should work, but only between
related processes where the parent process creates the semaphore before
forking and no exec is done. This is because a sem_t is a pointer to a
structure containing the kernel level semid_t (and a mutex, condvar and
the like for process-private semaphores). sem_init() will allocate this
structure using malloc(3).
Changing sem_t to be a structure would be the obvious way to fix this,
but I think this cannot be versioned properly. For example, if someone
puts in the public header file of their .so:
struct my_struct
{
int foo;
sem_t bar;
int quux;
};
Changing the size of sem_t will break this. Also, assuming symbol
versioning were to be used, if you compile the .so for FreeBSD 7 and the
app for FreeBSD 8, the FreeBSD 8 sem_* functions will get FreeBSD 7
style sem_t's.
If process-shared semaphores really work, then the above structure is
not a pathological case. Effectively, sem_t is carved in stone. So
process-private semaphores should continue to have most of their stuff
in a separately allocated structure, to preserve flexibility.
Perhaps a better method is to set bit 0 of the sem_t to 1 and use the
other bits to store the semid_t.
--
Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090601161903.GA40377>