dtrace discuss - Oct 2008 - Suggestion for new destructive action: yield()

With the limitations that are built in with chill(), plus the
implementation being a busy-wait, I''d like to suggest that
another method for "suspending" the current thread''s
operation: yield().

The premise of it is the same as the system/function call:
remove the current thread from the CPU and encourage
it to schedule another one for execution.

The target of this is race condition testing using dtrace.

Thoughts?

Darren

On Tue, Oct 14, 2008 at 05:45:50PM -0700, Darren Reed
wrote:
> With the limitations that are built in with chill(), plus the
> implementation being a busy-wait, I''d like to suggest that
> another method for "suspending" the current thread''s
> operation: yield().
Romantic, but impossible: we instrument arbitrary contexts, and we have
no way of calling into the system to do much of anything, let alone
something as involved as yielding the CPU...

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems Fishworks.       http://blogs.sun.com/bmc

On Tue, Oct 14, 2008 at 05:45:50PM -0700, Darren Reed
wrote:
> With the limitations that are built in with chill(), plus the
> implementation being a busy-wait, I''d like to suggest that
> another method for "suspending" the current thread''s
> operation: yield().
> 
> The premise of it is the same as the system/function call:
> remove the current thread from the CPU and encourage
> it to schedule another one for execution.
> 
> The target of this is race condition testing using dtrace.
Hey Darren,

So it would just poke the current thread off the CPU? That could be pretty
tricky, and we''d have to do it asynchronously with respect to the probe
firing. I''d suggest that you might be better served by using the stop()
action and the system() action with prun(1) to get it moving again.

Adam

-- 
Adam Leventhal, Fishworks                     http://blogs.sun.com/ahl

stop()+prun would freeze the whole process... I think he wants other threads to
continue (possibly doing bad things) while the current thread is stopped. Some
other thread might take the current thread''s place when prun gets
things moving again, but it seems an awfully expensive and roundabout way to
achieve the effect.

Besides, this can''t possibly be worse than raising a signal from
dtrace... it should be possible to set some flag in the kthread and have
appropriate code check it "soon," where "soon" usually means
"before return to user space." Something similar to how how
issig_forreal() checks the dtrace_signal flag, but I''m not a kernel
expert to know whether there''s a similarly convenient spot for
inserting a scheduler decision.
--
This message posted from opensolaris.org