give up time slice - how?

[Ashmeet S Sidana]

A  few days back I posted the following article, but I haven't seen
any followups or replies yet. Since I certainly don't consider myself
a wizard :-) I  can only assume:

  1. The article didn't make it out (hence the repeat).
  2. The problem is so obviously simple that nobody considered it
     worth replying.
  3. This is a well known problem in unix that hasn't been solved.

If it is (2) or (3), could somebody please let me know. 

Thank you.

---Ashmeet

-------------------------------------------------------------------------------
ORIGINAL POSTING
-------------------------------------------------------------------------------

Subject: give up time slice - how?
----------------------------------

What is the easiest (lowest overhead) method to voluntarily give up the rest of
your time slice in Unix or a user process?

I am working on a problem where I need to give up my time slice when certain
conditions occur in my code in shared memory.  Note that these conditions
are independently detected by the user processes - no system call (specifically
no semaphores etc.) are being accessed here.

I would like to do this in a way such that I get scheduled in the earliest
possible subsequent time slice - I understand that other CPU bound processes
could make this very long etc. but that doesn't matter.

I thought of doing a select(2) with a blank fd vector and timeout zero.
Will this work? Or will the kernel just reschedule me immediately (within
the same time slice) since I'm not waiting for anything? Any easy way
to detect this?

If it will work how long after the select does the kernel put me on
the run queue again? (i.e. other than other processes of higher run
priority what can come in my way).

	> On RTFM'ing carefully I have found that this approach will <
	> will not work, since the semantics of a blank fd vector    <
	> are different. So please ignore this                       <

BTW, I am doing this on a HP-UX 9000/800 system, if that makes a 
difference. However, if possible I am interested in solutions on other
systems too (specifically IBM RS/6000, SUN SPARC 1's and DEC 3100s).

Thank you.

---Ashmeet Sidana
   sidana at cs.stanford.edu