Re: Boolean Thread::Semaphore ?

[Anonymous Monk]

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;

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).

[BrowserUk]

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.

1. a queue can only be accessed by one user (reader or writer) at a time, regardless of how much is does or can contain.
2. 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.

3. 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.

[chrestomanci]

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.