relinquishing a time-slice
Luke
in Unix/Linux using POSIX compliant threads?
In windows, it's done with a Sleep() as noted with this excerpt taken from
the Platform SDK "remarks" section of the Sleep() function:
-- A thread can relinquish the remainder of its time slice by calling this
function with a sleep time of zero milliseconds. --
Reason being: I have a thread waiting for a mutex to unlock and instead of
continuously looping, I'd like to relinquish the time slice so the thread
responsible for unlocking the mutex can continue its work without having to
wait for the previous thread's wasted time-slice.
Thanks, LJE
Nikhil Deo
Luke Eitneier
However, I found this very interesting news-thread posting:
http://www.cs.helsinki.fi/linux/linux-kernel/2002-24/0539.html
"Luke" <leit...@zortec.com> wrote in message
news:ap6flq$k...@dispatch.concentric.net...
Luke Eitneier
relinquishing a time-slice as opposed to sched_yield which is defined to
re-que the "process" in the schedule que.
kudos to Nikhil Deo.. Thanks...
"Luke Eitneier" <leit...@zortec.com> wrote in message
news:ap6jko$k...@dispatch.concentric.net...
Steve Watt
Luke <leit...@zortec.com> wrote:
>Is there a way (function) for a thread to relinquish its current time slice
>in Unix/Linux using POSIX compliant threads?
sched_yield(). Anything that says it affects a process hasn't updated
their man pages for threads.
>In windows, it's done with a Sleep() as noted with this excerpt taken from
>the Platform SDK "remarks" section of the Sleep() function:
>-- A thread can relinquish the remainder of its time slice by calling this
>function with a sleep time of zero milliseconds. --
>
>Reason being: I have a thread waiting for a mutex to unlock and instead of
>continuously looping, I'd like to relinquish the time slice so the thread
>responsible for unlocking the mutex can continue its work without having to
>wait for the previous thread's wasted time-slice.
If you're waiting for a mutex to unlock, lock the mutex. You'll wait
until it gets unlocked. Why poll when you can block?
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9"
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...
Luke Eitneier
relinquish it?
Also, by blocking, do you mean the use of pthread_mutex_lock()... (POSIX)
and EnterCriticalSection()... (Win32)?
Bare with, I'm new to this... Thanks...
"Steve Watt" <st...@nospam.Watt.COM> wrote in message
news:H4G4A...@Watt.COM...
Patrick TJ McPhee
Luke Eitneier <leit...@zortec.com> wrote:
% Will blocking use up the entire time-slice for that thread or immediately
% relinquish it?
It depends a bit on the implementation. A good one will do whatever
makes most sense under the circumstances.
--
Patrick TJ McPhee
East York Canada
pt...@interlog.com
Steve Watt
Patrick TJ McPhee <pt...@interlog.com> wrote:
>In article <ap6p54$k...@dispatch.concentric.net>,
>Luke Eitneier <leit...@zortec.com> wrote:
>% Will blocking use up the entire time-slice for that thread or immediately
>% relinquish it?
>
>It depends a bit on the implementation. A good one will do whatever
>makes most sense under the circumstances.
Actually, I don't think I can come up with anything that will use up the
time slice before relinquishing, except maybe some sort of adaptive
spinlock.
(To Luke:)
Most systems, when attempting to lock a resource that is already
locked, will immediately relinquish the time slice and place the
requesting thread on some wait queue. This is true in all of
the POSIX implementations I am familiar with (though not strictly
required by the standard). I (thankfully) don't use the Win32
API, so I don't know for certain. I would be surprised if it
did anything but immediately relinquish control, though.
Kilgaard
> (To Luke:)
> Most systems, when attempting to lock a resource that is already
> locked, will immediately relinquish the time slice and place the
> requesting thread on some wait queue. This is true in all of
> the POSIX implementations I am familiar with (though not strictly
> required by the standard). I (thankfully) don't use the Win32
> API, so I don't know for certain. I would be surprised if it
> did anything but immediately relinquish control, though.
Win32 will also immediately relinquish control.
David Butenhof
In trying to decide to which of the entries in the growing thread I should
respond, I ended up all the way back at the beginning. So, OK.
First, if you need to worry about whether locking a mutex will block the
thread that owns the mutex, you're on a broken system and nothing you can
do will really help.
When you lock a mutex, the implementation is responsible for determining how
best to wait. Some implementations will spin, at least for a while, before
blocking. But any implementation that does this on a uniprocessor is
seriously broken. Ideally, in fact, it will spin only when it knows that
the current owner is currently running on another processor -- but in
practice that knowledge is often too expensive to acquire, and too
unreliable to use. (Still, IDEALLY, the mutex lock implementation would
know and act on that information.)
On a uniprocessor, a spin is always stupid -- because it can only waste
time.
Now, sched_yield() vs nanosleep() or other blocking alternatives. First, you
shouldn't worry about this in the first place, and, if you're convinced
that the implementation is so broken that you NEED to worry about it, you
should instead be worrying about finding a better implementation. However,
let's imagine you're writing an implementation, and want to use portable
functions to create a multi-stage spin backoff. That is, you want to spin
for a bit, then ensure the current owner has a chance to run, then spin a
little more, and then finally block on the mutex. You don't KNOW whether
the owner is trying to run, or already running somewhere else. Yield will
give it a chance IF it's waiting for your processor, and otherwise
immediately return to let you continue spinning. (That's ignoring
scheduling policies and priorities, which is a good thing to ignore here
because if you're playing with them everything gets more complicated.)
If, on the other hand, you were to sleep for some period of time, you're
blocking the thread even if there's no other thread waiting for the
processor. And blocking for a fairly big chunk of time, because even though
nanosleep allows you to SPECIFY time in nanoseconds very few
implementations can actually block you for less than milliseconds. (An
awfully large number of instruction cycles nowadays.) So you block, the
owner unlocks... and you're just sitting there, snoozing away the day,
completely missing the chance to actually LOCK the mutex. In fact, if
there's any contention for the mutex (and clearly there IS, or you wouldn't
have this problem in the first place), you may NEVER get the lock because,
as in the parable of the tortoise and the hare, a lot can happen while
you're taking a nap.
--
/--------------------[ David.B...@hp.com ]--------------------\
| Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/
Patrick TJ McPhee
% In article <egDt9.15360$qh1.2...@news.ca.inter.net>,
% Patrick TJ McPhee <pt...@interlog.com> wrote:
% >In article <ap6p54$k...@dispatch.concentric.net>,
% >Luke Eitneier <leit...@zortec.com> wrote:
% >% Will blocking use up the entire time-slice for that thread or immediately
% >% relinquish it?
% >
% >It depends a bit on the implementation. A good one will do whatever
% >makes most sense under the circumstances.
%
% Actually, I don't think I can come up with anything that will use up the
% time slice before relinquishing, except maybe some sort of adaptive
% spinlock.
That's roughly what I was thinking of.