> > In that case, Valgrind is somewhat irrelevant. An equivalent problem > > (it seems to me) is this: for a threaded program running natively, > > how do you force the Linux kernel to run a thread of your choice > > next, when there is more than one runnable thread? I don't know > > how. You can do sys_yield(), but that's only a hint to the kernel; > > it doesn't _force_ anything to happen. > > You force it by ensuring that all threads except the one you want to run > are blocking on some resource. That way the kernel has no choice about > which thread to schedule.
Yes, I guess so. Although I'm not sure how this could be implemented. The trick with the pipe in sema.c implements a lock well enough, but how does one implement a lock in which (1) the unlocker can control which thread gets the lock next, and (2) that signalling is somehow implied to the kernel, so as to force it to "decide" on our behalf? I'm not sure. Also, deciding ourselves which thread is next to run is dangerous. If we decide to run thread X (and cause all the rest to be blocked), but for some reason that we don't anticipate, the kernel believes X to be blocked, then the system will deadlock. You may remember, a long time ago (in 2.4.0 days) there was at one point a patch (committed, and later removed) which changed the exit order of threads in so that (iirc) the root thread for the process was not allowed to exit until all other threads had exited. This was in order that shell scripts, etc, waiting for the root thread to finish, would be guaranteed that the final error messages, stats, etc, were printed before the root thread exited. But this effectively added inter-thread dependencies which were not present in the original program, and caused complex threaded apps to sometimes deadlock at exit, most notably OpenOffice. As a result of that I'm leery about screwing with thread scheduling at all. IMO we should leave that stuff entirely to the kernel. I think the original poster (Felix) would do well to explain what problem he is trying to solve by scheduling threads himself. Perhaps then we could think of some other solution. J ------------------------------------------------------------------------- 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
