|
From: Jeremy F. <je...@go...> - 2004-12-16 23:31:29
|
On Thu, 2004-12-16 at 12:33 +0000, Greg Parker wrote: > In a month or two I should have a better idea of where Valgrind's > OS-specific assumptions are, and perhaps some ideas of how it > could be layered to make it more portable. My porting procedure > is still mostly "doesn't build? comment it out!" so I haven't > really looked at most of the system yet. Nick has already made a good start on that; there's now a good framework for determining where various pieces of code should live, depending on whether they're CPU, OS or CPU+OS specific. There's still a lot of stuff to be moved, but that process will necessarily be driven by ports. > > My solution is as follows: Each thread in the inferior is a real > Mach thread. Valgrind contains no scheduler and no reimplementation > of the threading primitives. Instead, a single coarse-grained mutex > is used to ensure that only one thread is executing in the Valgrind > core at a time. If some thread is about to start a blocking syscall, > Valgrind's syscall wrapper relinquishes the mutex, executes the syscall, > and then blocks on the mutex before continuing execution. New threads > block on the mutex before starting at their simulated entry point. > Threads that have exhausted their basic block counter release the > mutex and yield. The thread_suspend() trap throws in a few more > curves, but nothing insurmountable. Almost everything else is handled > automatically by the kernel's scheduler and threading primitives. Yes, that's the direction we'd like to go anyway. I've been looking at restructuring the core's thread support in a similar way. The plan is to drop the whole Valgrind pthreads layer (mostly), and implement Linux's threading at the clone level, layered on top of a very simple internal thread model (which is basically "threads are either running code or are blocked in a syscall"). One of my hesitations was that I wanted to see how other systems do threading to make sure that we can use a similar mechanism across multiple OS's: MacOS's Mach threading was a particular concern, so the fact that you independently came up with the same scheme is very reassuring. I was planning on keeping the existing deterministic scheduling, rather than letting the kernel scheduler make the decision; I'm concerned that we'd get strange competition between IO and CPU bound threads, since CPU-bound threads will be about 20-50x more CPU consuming, but IO-bound threads will look much the same to the kernel. So, I was thinking, one mutex per thread, and each thread chooses and wakes its successor as it is about to give up the CPU. BTW, what's the thread_suspend trap, and what difficulties does it introduce? > So far, this mechanism works well, though I haven't thrown any > heavily multithreaded tests at it yet. I haven't examined the > possible interactions with signal handling, but signals are > uncommon in Mac OS X applications so I'm willing to ignore them > for now. The benefit is that I only need thin wrappers around > a handful of Mach traps and some mutex management in the syscall > handler. Yeah, that's great. J |