RE: [sv-ec] [sv-bc] Semaphore question

Cliff,

A common use for counting semaphores is to control access to a pool of
shared resources. Consider, for example, a semaphore used to control 
access to N resources (an N word memory for instance). When a process 
needs M words of memory, it executes a get(M) operation, and when it is
finished it executes a put(M) to make the resources available.
Next, consider the situation when processes require different amounts of
shared memory. Several processes require 1 word while others require 
the entire memory (N words). The "unfair" semaphore that the LRM
describes
allow up to N small processes to finish their job, regardless of whether
a 
process that requires the entire memory is already waiting on the queue.
This "barging in" of a process with a smaller requirement is what I
meant by
"throughput advantages" in my earlier message: More (small) processes
are
able to finish at the cost of perhaps starving a larger process.

	Arturo

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Cliff Cummings
Sent: Tuesday, September 20, 2005 8:07 AM
To: sv-bc@eda.org; sv-ec@eda.org
Subject: RE: [sv-ec] [sv-bc] Semaphore question

Hi, Jonathan -

Thanks for the reply. I agree that semaphores may not be best suited for
the examples I gave, but I am trying to figure out reasonable use-models
for the available semaphore capabilities.

Seems like taking and putting a single key will be the most common
use-model, but I tried to figure out what reasons might exist for taking
and putting multiple keys or putting extra keys into the bucket.

If only the simple use-model were applicable, why did somebody add the
other capabilities as opposed to adding safeguards that would keep
engineers from requesting multiple keys or putting back more keys than
they have taken?

Any use-model thoughts? You have seen my feeble attempt to come up with
examples of possible usage.

Regards - Cliff

--- Jonathan wrote ---------------------------------------
Whilst we obviously need to clarify the defined behaviour,
for my $0.02 you're abusing semaphores here: it's a very
low-level synchronization construct, and what you're
suggesting smacks of using a buggy whip as a cruise control.
Be grateful that at last we have a reliable mutex, and
write custom resource control classes to do the interesting
things you describe; these classes can use one or more
semaphores, or mailboxes, in straightforward ways.


Just my bigoted opinion as usual :-)
-- 
Jonathan Bromley, Consultant