From owner-freebsd-stable@FreeBSD.ORG Mon Jun 1 16:19:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5841010657AD for ; Mon, 1 Jun 2009 16:19:19 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 13C358FC1F for ; Mon, 1 Jun 2009 16:19:19 +0000 (UTC) (envelope-from jilles@stack.nl) Received: by mx1.stack.nl (Postfix, from userid 65534) id 66BC635994D; Mon, 1 Jun 2009 18:19:18 +0200 (CEST) X-Spam-DCC: z.dcc-servers: scanner01.stack.nl 1049; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on scanner01.stack.nl X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Relay-Country: _RELAYCOUNTRY_ Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 162B135993C; Mon, 1 Jun 2009 18:19:16 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 66B17228BC; Mon, 1 Jun 2009 18:19:03 +0200 (CEST) Date: Mon, 1 Jun 2009 18:19:03 +0200 From: Jilles Tjoelker To: Vlad Galu Message-ID: <20090601161903.GA40377@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: Unnamed POSIX shared semaphores X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 16:19:20 -0000 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