Thread yields cpu WITHOUT forcing process to lose cpu

Question

I would like to know how a thread should yield the CPU without forcing its process to lose the CPU. The candidates are thr_yield, sched_yield and yield.
"The yield() function causes the current lightweight process to yield its execution in favor of another lightweight process with the same or greater priority." This looks promising if the LWP is bound to the thread in question, but I still don't know what would happen if the thread has process contention scope.
"The sched_yield() function forces the running thread to relinquish the processor until the process again becomes the head of its process list. It takes no arguments." Yuck! Does this mean that the process is booted by the operation? I would have preferred it if no mention of process had been made."
"The thr_yield() function causes the current thread to yield its execution in favor of another thread with the same or greater priority." Perhaps the best candidate. This does, of course, push us in a direction away from portability unlike sched_yield.
I was just wondering if anyone knew the answer to this question. Thanks in advance to anyone who takes the time to reply.
Sincerely,
jonnie savell

Answer 1

Hi,
without AWR/ASH your options for retrospective troubleshooting are very limited. You can use statspack -- but unlike AWR, it requires the DBA to either launch it manually, or manually schedule a database job for this purpose.
V$ views won't help you because they either represent statistics accumulated since the last instance startup, or the current state of the database (like V$SQL which externalizes the current contents of the library cache -- so if a cursor is aged out, you won't find it there). What you need is differential stats -- i.e. differences between snapshot (e.g. before and after a problem), there are no default mechanisms in the database for that (other than AWR or analogs).
You query is meaningless because:
- cursors may have been aged out
- cursors may have later last_load_time (because after being executed in the specified interval, they may have been active at a later time)
- even if you managed to get an accurate number of cursors accessed during a certain interval, what would you do with it?
Pretty much your only option is to do log mining, if you have archived logs for the period of interest. It's time consuming, but it will give you the entire history of all SQL run, if you really need it.
Best regards,
Nikolay