|
From: Julian S. <js...@ac...> - 2012-02-15 09:35:42
|
> Note however that I am not at all sure that the (hacked) prototype > is the correct way to go. Me neither; but OTOH we have to start to learn about the problem somehow, and this seems as good a way as any. Even if it is nothing like how the final implementation will look. > Or at least, there is still a whole bunch > of unclear points to me. Me too :-) One conceptual distinction which I think will be useful (or, really, essential) is distinguish two different problems: (1) making the core multithreaded (that is, having it run with --tool=none reliably) and (2) making the tools multithreaded. (1) is a lot easier than (2), and I would suggest to aim to achieve it as a first step. Speaking at least for Memcheck and Helgrind, both tools currently rely heavily on the single threadedness. I have studied Memcheck's design in quite some detail w.r.t. threading, and many of the space saving optimsations in it will be invalidated by threading. In short it will require a complete reimplementation of the shadow memory stuff (mc_main.c, basically). Assuming we concentrate on (1) for now .. (which for sure is by itself more than enough complexity ..) > For example: we have two threads which are running user code. > (so, each thread has a "read lock" via the scheduler locking, > aimed at protecting a.o. the translation table). Urr, so just to concentrate on the basic execution mechanism .. If we have all threads executing translations in parallel and assume there is no problem with locking .. fine. But suppose one thread leaves generated code because a translation needs to be made. It's probably doable to make VEX run MT to do the translation, but when we come to add it to the translation table and tt_fast cache .. do we need locking there? And if a thread leaves generated code in order to remove a translation for whatever reason .. how do we do that without crashing the other running threads? J |