Henry,
You are welcome. I have not read Steve's book, so can't comment
on the prose there, but..coupla points:
0) Semaphores usually (but not always!) protect "binary" resources...
things requiring mutual exclusion ("one at a time") or which have
producer/consumer relationships ( "i put a value in, you take it out
for further processing". think "PQO" ). (There *are* things called
mutex locks which are more efficient than semaphores for pure mutex
applications...)
1) semaphores need not be "binary". Eg, I can protect a multibuffer
resource with a semaphore that decrements down from MAXBUFFER.
When it hits zero, there are no more buffers in that resource.
(And then it "blocks")
2) semaphores can be implemented in the OS or the dbms kernel
(for the former, consider the family of SEMOP() calls.)
3) processes may act differently upon resources acquisition failure,
they wait (by CPU spin, by sleep, by erroring out) or they can
"do something else" for a while and re-check. In all cases, it
is the interested process who has the responsibility to acquire
resources. A semaphore is not responsible for the acquisition of
resources, only the *protection* of them.
So, to answer your question : "If I am sleeping and the latch frees,
who knows I need that semaphore?" The answer is: "You do." ( "you" in
this context, is the process needing the resource, of course.)
And, to answer your question: "Are all waiting processes posted with
the semaphores going on/off/on/off?" the answer, for Unix, is "No."
Semaphores do not "broadcast". They are merely "set" or "not set".
And, for a punchline, kind of: People sometimes confuse "postwait" drivers
with semaphores. They are NOT the same. Much different animals. But, they
can share functionality in some cases ( oracle is one! ) and so there is
room for confusion.
hth
Ross
-----Original Message-----
From: Henry Poras [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 14, 2001 11:01 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Oracle Internals
RM,
Thanks. Intuitively that seems like the way it should work. However it
appears to contradict what Steve wrote in his book about a sleeping process
waiting on its semaphore. I wonder if this is just a publishing error, or if
I am missing something in my understanding. I usually find it a good policy
to give Steve Adams the benefit of the doubt.
Henry
-----Original Message-----
Sent: Wednesday, March 14, 2001 9:06 AM
To: Multiple recipients of list ORACLE-L
HP, it is sleep/wake/check. it is up to the process to acquire the
resource. AFAIK, there is no message-passing type of algorithm to
tell waiting (whether spinning or sleeping) processes when the
semaphore becomes unset ( ie the resource is available ) Sleeps
are expensive in Latchville, and you can track their occurence
via v$latch_waits and the SLEEP* columns.
hope this partial answer helps.
-----Original Message-----
]
Sent: Tuesday, March 13, 2001 10:25 PM
To: Multiple recipients of list ORACLE-L
I have been rereading Steve Adam's book a bit more carefully and have a
question. Just wondering if anyone has any answers.
When talking about latch sleeps, the book states "a process sleeping for a
latch waits on its semaphore". However, latches don't support queuing and a
number of processes may be waiting for the same latch. If I am sleeping and
the latch frees, who knows I need that semaphore? Are all waiting processes
posted with the semaphores going on/off/on/off? or is no semaphore posted
and the processes go sleep/wake/check/sleep/wake/check? I can't quite
picture the details here.
Henry
--------
Think you know someone who can answer the above question? Forward it to
them!
to unsubscribe, send a blank email to [EMAIL PROTECTED]
to subscribe send a blank email to [EMAIL PROTECTED]
Visit the list archive: http://www.LAZYDBA.com/odbareadmail.pl
<http://www.LAZYDBA.com/odbareadmail.pl>
Tell yer mates about http://www.farAwayJobs.com <http://www.farAwayJobs.com>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
<http://www.orafaq.com>
--
Author: Henry Poras
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Henry Poras
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
