Re: Latch spin - OS timeslice

I shouldn't have mentioned latch_spin_count, because I think it went defunct on most
platforms a long time ago. I have always assumed since that the necessary latch
space preparation etc. (there are 168 bytes in a logical latch, despite the fact that a physical latch is notionally one bit) was sufficient for the 'tiny_active_wait' interval.

(I only mentioned it because I can never remember which one was which).

I can't imagine how you could work out
(reliably) how long a 'gimme plus tiny_active_wait' lasts, unless you could find a way to make one process hold a latch indefinitely then get another process to grab it.

--
Jonathan Lewis
http://www.jlcomp.demon.co.uk

Next Seminar - UK, April 3rd - 5th
http://www.jlcomp.demon.co.uk/seminar.html

Host to The Co-Operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html

Author of:
Practical Oracle 8i: Building Efficient Databases


Alex Bardos wrote in message ...


>My understanding, based primarily on "Oracle Internal Services for

>Waits, ..." by Steve Adams, is as follows:

>

>Oracle goes:

>

> ______

>S |

> |gimme

> |tiny_active_wait

>P |gimme

> |tiny active wait

> |gimme

>I |tiny_active_wait

> |...

> |...

>N |gimme

> ______

>

>where the amount of time spent in "tiny_active_wait" used to be

>configurable (Oracle 7) through _LATCH_SPIN_COUNT; the number of

>"gimme + tiny_active_wait" (# of attempts to acquire a latch) in the

>outer SPIN cycle configurable through _SPIN_COUNT (default 2000 ?).

>I would expect the "tiny_active_wait" to be negligible relative to the

>time slice. I would expect the whole SPIN cycle to be comparable to

>the time slice, still smaller though to increase chances of not being

>preempted by the OS after the time slice is up.

>Any idea how much time one iteration of "gimme + tiny_active_wait"

>takes ?

>