Re: [boost] Re: no semaphores in boost::thread

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2003-06-07 08:56:28

Alexander Terekhov wrote:

> I see that you're also "not fond" of following the links. Okay.

that's starting to get annoying...

I did follow the links, I just don't happen to agree with what
was said there. No need to paste it again here.

> This is far from elegant, because the queue data structure already knows the
> number of messages either implicitly or with an extra counter of its own.

well, I need to know it explicitely when I want to extract the next one,
so either the queue caches its length, or I have to count each time.

> Usually, what is most relevant is whether or not the queue is empty.
> So the semaphore is coding redundant information. Note that at times,
> this information will be out of sync. For example, say you have
> this sequence of actions:
> 
>     lock();
>     append(item);
>     unlock();
>     signal(semaphore);
> 
> In between the append and signal operation, the queue has N+1 items,
> but the semaphore's value is out of date at N. 

so what ? the 'real' queue length is kept private and doesn't matter
much. It's the signaling of the semaphore that makes the change public.

> A semaphore has an internal lock which protects incremnts and decrements
> of its internal counter. There is no way to extend that lock to cover
> additional data such as a queue. With a mutex and condition variable,
> the entire queue can be treated as a semaphore based on its *own*
> state!

I never said it can't. Besides, I'd like to argue about your description
of the implementation of semaphores. There is no need for a lock around the
internal counter, if the semaphore is implemented with atomic counters.
Of course, that's true only on platforms that support atomic counters...

And then there is the other semaphore I use to count the free slots,
which you didn't comment on, probably because it didn't fit into your
arguments...

This is my last mail in this thread. It's not related to boost any more
anyways. We have to agree to disagree.

Regards,
                Stefan