sidana@Neon.Stanford.EDU (Ashmeet S Sidana) (07/01/91)
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@cs.stanford.edu