RE: Oracle Internals

From: Mohan, Ross <MohanR_at_STARS-SMI.com>
Date: Wed, 14 Mar 2001 14:22:28 -0800
Message-ID: <F001.002CCA7C.20010314111524@fatcity.com>

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

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")
semaphores can be implemented in the OS or the dbms kernel
(for the former, consider the family of SEMOP() calls.)
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:Henry.Poras_at_ctp.com] 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 oracledba-unsubscribe_at_LAZYDBA.com to subscribe send a blank email to oracledba-subscribe_at_LAZYDBA.com 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: Henry.Poras_at_ctp.com 


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: ListGuru_at_fatcity.com (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: Henry.Poras_at_ctp.com


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: ListGuru_at_fatcity.com (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).

Received on Wed Mar 14 2001 - 16:22:28 CST