Re: Boolean Thread::Semaphore ?

While others have commented on alternative methods to the overarching problem, I wanted to address the specific question of a 'boolean' semaphore. One 'brain-dead' simple approach would be to sub-class Thread::Semaphore such that the ->up() operation sets the semaphore to 1 rather than incrementing it.

package Thread::Semaphore::Boolean;

use threads::shared;

use parent 'Thread::Semaphore';

# Create a new 'boolean' semaphore
sub new {
    my $class = shift;
    return $class->SUPER::new(1);
}

# Set semaphore's count to 1
sub up {
    my $sema = shift;
    lock($$sema);
    $$sema = 1;
    cond_broadcast($$sema);
}

1;
[download]

Again, this is 'brain-dead' in that elementary uses of ->down() and ->up() will work, whereas other 'fancy' operations may break (e.g., $sema->down(2) would 'hang' because the 'boolean' semaphore would never be greater than 1).

Comment on Re: Boolean Thread::Semaphore ? Download Code

Replies are listed 'Best First'.
Re^2: Boolean Thread::Semaphore ? by BrowserUk (Patriarch) on Feb 09, 2012 at 19:33 UTC
This is a very bad idea. A counting semaphore is fundamentally the wrong mechanism() for watermarking a queue; so futzing with the API of a counting semaphore to allow it to be used (badly) for this purpose is just all kinds of wrong. ()In brief, A counting semaphore is designed for controlling concurrent access to a resource that is limited but has multiple instantiations. A queue, even a pre-limited queue, does not fit this criteria. a queue can only be accessed by one user (reader or writer) at a time, regardless of how much is does or can contain. the availability of a queues resources is not determined by the actions of competing consumers -- the reason d'etre of the counting semaphore -- but rather by the actions of the producer. They are very different animals. Having the consumer(s) of a queue effectively control the producer(s) for that queue, requires multi-way synchronisation, and defeats the primary purpose of the queue: that of acting as a flexible buffer between producers and consumers to avoid the need for and problems associated with such synchronisation. Those problems include: Consumers and producers can become 'step-locked'. The flow falls into a pattern of the consumer(s) all wasting many time-slices (and expensive context switches) waiting for the producer(s). Then alternately, the producer(s) all waste time-slices waiting for the consumer(s). The flow becomes lock-stepped wasting many context switches between each forward step. The very purpose of queues is to alleviate this problem by acting as a flexible buffer removing the need for synchronisation. See 940030 for a little more discussion. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. The start of some sanity?	[reply]
Re^2: Boolean Thread::Semaphore ? by chrestomanci (Priest) on Feb 09, 2012 at 16:25 UTC
Thanks, that is a good solution, though as you say, not very robust. I think a robust implementation would be a good idea, so with that in mind I have emailed the author of Thread::Semaphore about adding the feature, either via a subclass as you suggest, or by adding the feature to the existing core module. Don't worry, whatever code I submit will robust and be properly tested to avoid the bugs you suggest.	[reply]