Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27241
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ioplex.com from 66.220.1.142 cause and error)
Date: Tue, 2 Jan 2007 14:36:27 -0500
To: "Wojciech Malota" <wojtekm86@konto.pl>
Cc: internals@lists.php.net
Message-ID: <20070102143627.0c0e6985.mba2000@ioplex.com>
In-Reply-To: <3E.25.03249.EBCAA954@pb1.pair.com>
References: <B7.00.04701.E3B0A954@pb1.pair.com>
	<20070102122940.662ebd49.mba2000@ioplex.com>
	<3E.25.03249.EBCAA954@pb1.pair.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Semaphores - feature request
From: mba2000@ioplex.com (Michael B Allen)

On Tue, 2 Jan 2007 20:04:19 +0100
"Wojciech Malota" <wojtekm86@konto.pl> wrote:

> > I don't understand. If your "FIFO" is some kind of refcount that won't
> > work because the refcount would not be shared by multiple separate
> > PHP processes. You would have to put the refcount in shared memory
> > and even then there's no guarantee that the semaphore will be cleaned
> > up properly because any exit routine will not run if the application
> > is killed, crashes, aborts, etc.
> 
> FIFO in this context is a queue of processes which are waiting for acquiring 
> occupied semaphore.
> This queue is managed by operating system and is implemented in mechanism of 
> semaphores.
> I think that there must be possibility to check if this queue is empty.

I'm still very confused. I think your terminology is inaccurate.

If semop is called with sembuf.sem_op < 0 to indicate that the semaphore
should be decremented then a semphore value of 0 will cause the caller to
wait. Is this what you mean by "FIFO" and queue of processes waiting to
"acquire" the semaphore?

If yes, then it would not matter if there were no callers waiting
because that is a valid condition during which the semaphore should not
be removed.

For example, one process may call semop decrement the semaphore to
0 (to mean "locked"), return and then go off to perform work in the
"critical section". At that point there are no callers waiting. Now if
a second process calls semp it will block because the semaphore value
is 0. When the first process completes its work it will call semop with
sembuf.sem_op > 0 to increment the semaphore value. That will signal
the second process to wake up, find the semaphore value greater than 0,
decrement it, and continue on to perform it's critical section.

So the point is that you cannot remove the semaphore when there are no
callers waiting in semop because that is a perfectly valid state.

Mike

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/