Julian Seward wrote:
> On Tuesday 28 October 2008, Felix Schmidt wrote:
>> how can i tell the valgrind scheduler to stop the current thread and
>> start the next one?
>
> You can't. The kernel chooses which thread runs next, not Valgrind.
> The only thing Valgrind does is to guarantee that only one thread
> runs at once. But it does not make scheduling decisions.
If I understand the OPs plight correctly; he wants (like I do) to
hint/instruct valgrind what choice it should make and/or force a
reschedule on demand.
I can see good use for this myself for all modules in VG
(memcheck/helgrind/etc...).
At the bottom of this email is a code representation of such an API.
<helgrind-soap-box-mode>
This would lead into then having a way to notify HelGrind at moments of
interest and regions of memory to check access of. For example when a
threading lock is taken (a mutex) you want to suspend the current thread
(that took the lock) and let every other thread run as far as they can
to try to expose a memory access.
Ideally you'd:
* take the lock
* instruct valgrind explicitly what memory to scrutinize (pointer plus
length with allowed access mode)
* instruct valgrind to keep this thread blocked for a period of time
and let other threads run (in an attempt to violate the memory rules you
defined in the point above)
* then pass control back to this thread, to actually do its work
* then remove the lock (unlock)
* then ask valgrind to examine, summarize and report on that window of
time in relation to this locking scenario.
The problem with not explicitly defining all memory you know you are (or
you might) access during the critical region is that you rely on the
actual bug to occur and a certain about of valgrind reverse engineering.
Where as if I can explicitly mark out the worst case memory access
scenario that this lock is meant to protect (for example the whole
buffer space "char buffer[1024];", as opposed to just the bits it
accessed) and
If I can control thread scheduling to some degree so that I can allow
all other threads to run for a bit I can then write a testcase to
agressively exposed threading bugs in my code.
I have not been able to find HelGrind as-is that useful in supporting
multi-threaded debugging exercises.
</helgrind-soap-box-mode>
Fictitious code representation of such an API:
/* This is an application defined thread scheduler callback function */
int
my_scheduler_implementation(tid_t current_tid, int event, struct
argument_return_data *data) {
if(some_external_flag && event == VG_EVENT_USER1) {
tid_t next_tid = pick_next_tid_by_magic();
/* there maybe other data to pass back to VG */
data->next_tid = next_tid;
return VG_SCHED_RETURN;
}
return VG_SCHED_DEFAULT; /* just let vg do whatever it does by
default
for this event type */
}
extern int vg_thread_control(int event, void *event_arg);
/* I demarcate the start of the region of execution where I want some
explicit control over scheduling, this allows vg to init hooks if there
ends up being a speed penalty for using this API */
vg_thread_control(VG_ENABLE_EXPLICT_RESCHED_MODE,
&my_scheduler_implementation);
/* your basic explict switch */
tid_t tid = 12345;
vg_thread_control(VG_SWITCH_TO_THREAD, &tid);
/* your basic attempt to let another thread have the CPU */
vg_thread_control(VG_YIELD);
/* application specific meaning to custom scheduler or treat as yield */
vg_thread_control(VG_EVENT_USER1);
/* I'm done with needing explict control go back to VG default behavor */
vg_thread_control(VG_DISABLE_EXPLICIT_RESHED_MODE);
VG would keep an LRU list of most recently run threads, forcing
switching to a thread puts that thread in control and at the top of the
list. Yeilding CPU from a thread attempts to pass control to the next
thread down the LRU list (than the current thread executing). When it
drops off the bottom of the list VG would do whatever it currently does
now (which is always the scheduler of last resort).
When it drops off the bottom of the list it might pass another event to
my_scheduler_implementation(event=VG_LAST_RESORT) to give it one last
notification.
Then when VGs default scheduler selects the next thread to run there is
also another event simply to notify the custom scheduler this is
happening (for which the return value is ignored).
There are obviously problems with blocked threads being continuously
selected by the custom scheduler to run next. Maybe the custom
scheduler should have access to a thread map showing a list of all
threads, their threadid and their runnable state. If it selects a
blocked/stopped thread for execution this is treated as a "faux-pas"
resulting in VG using its default scheduler to select the next runnable.
Food for though I hope,
Darryl
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
