Re: Glib Semaphores

[Karl Nelson <kenelson ece ucdavis edu>]

[...]
> A possible advantage of semaphores is that because the shared data they protect
> is a simple counter, atomic operations may be exploited to perform the
> increment and decrement operations. For that, semaphores have to be implemented
> specially, rather than in terms of other primitives such as mutexes and
> conditions.  This advantage disappears when the semaphores are used in
> conjunction with data that must be separately protected anyway (such as
> consumer/producer queue), for then the counter might as well be made part of
> the queue structure and protected by the queue's mutex, e.g.

Probably true, but then some things are better represented one way 
while others are better represented in others.  I assume the user
will chose the most appropriate representation.

[...]
A typical example of producer/consumer expressed if lock step operation
is necessary can be cleanly written with semaphores like this. 

 main:
   // spawn threads
   process.down();  // wait until all processes die to terminate
   process.down();

 consumer:
   while (want_items)
     {
       consumer.down();
       // eat up an item
       producer.up();
       // do some more processing which is not shared
     }
   process.up();

 producer:
   while (can_produce)
     {
       producer.down();
       // produce some items.
       consumer.up();
       // more unshared processing
     }
   process.up();

Here, I don't need any more mutexs nor do I need to worry about
the recombining.  The semaphore process represents threads completed
so arguments about representing some queue length don't really 
apply.
     
[...]
> To prove that the queue is not
> misused, for example by trying to remove an item from the empty queue, one has
> to prove that the semaphores have reasonable values at all times.  In a trivial
> example, this doesn't pose a problem, but in large, complex multithreaded
> software, this kind of uncertainty can cause real headaches.

This simply means that semaphores weren't the proper way to express that
large, complex multithreaded software.  They do have their uses especially 
for tasks where you spawn some threads let then work and then recombine.
I certain don't think adding a semaphore concept is likely to force it
on the users.  

You seem to be implying that since you can do it one way, there is 
no need for a simpler to use concept for quick and dirty threading tasks.  
I think that it certain is safe for some tasks and some programmer will
find it of use.   Since the cost of adding it is fairly insignificant, I 
don't see the fact that is not useful in very complex programs as being 
a reason for not adding such a common concept.

--Karl