Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.programming.threads
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion A theoretical question on synchronization
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Kaz Kylheku  
View profile  
 More options Apr 22 2001, 3:22 pm
Newsgroups: comp.programming.threads
From: k...@ashi.footprints.net (Kaz Kylheku)
Date: Sun, 22 Apr 2001 19:22:53 GMT
Local: Sun, Apr 22 2001 3:22 pm
Subject: Re: A theoretical question on synchronization
Print | View thread | Show original | Report this message | Find messages by this author

On Sun, 22 Apr 2001 01:38:33 -0400, Timur Aydin <tay...@snet.net> wrote:
>Kaz Kylheku wrote:

>> However, the nature and variety of the objects provided by Win32 leaves
>> much to
>> be desired. Events are simply not very suited for solving a wide variety
>> of synchronization problems.  It's a lot easier to solve synchronization
>> problems

>> with condition variables because they have no programmer visible state.
>> The logic is based entirely on the state of your own data. Objects like
>> events or semaphores carry their own state; to solve a synchronization
>> problem, the programmer must bring about some meaningful association
>> between the semaphore's
>> state and the state of the program. In my programming experience, such
>> associations are fragile and difficult to maintain.

>One example where using a semaphore provides an elegant solution is a
>message queue. Whenever new messages are inserted into the queue, the
>semaphore count is increased by the total number of messages.

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

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!

So really, the samephore provides only a kludgy solution to synchronization
problems that are based on simple counting.

Also note that a sempaphore object can be trivially implemented using a mutex,
a condition variable, and a counter variable.  Mutexes and conditions cannot at
all be easily implemented using semaphores.

>A thread that
>processes these messages can just wait on the semaphore and will wake
>upprecisely as many times as there are messages in the queue.

This can be inefficient compared to just waking up, noting that there
are messages to be processed and removing all of them.

>This problem could also have been resolved with a win32 style event object,
>but it would not be as simple and intuitive as above and this would also
>lead to situations where the thread would unnecessarily wake up and find
>nothing in the message queue.

Note that an (auto reset) event is nothing more than a binary semaphore
which counts between the unsignaled and signaled states (effectively
0 and 1).

>This same problem would be very difficult to solve with a POSIX condition
>object.

Hardly at all!

>Because it is stateless, a thread has to be waiting at the instant
>that the condition is signaled, otherwise the thread would not notice.

>Say
>the thread is busy processing earlier messages and a new message arrived.
>The condition will be signaled, but the thread is not waiting on it at that
>instant, so the thread will not be woken up next time.

Do you have even the slightest clue on how condition variables are used
correctly or are you just guessing based on reading about them in a manual
page?

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google