|
From: Philippe W. <phi...@sk...> - 2012-02-15 20:25:03
|
On Wed, 2012-02-15 at 10:28 +0100, Julian Seward wrote:
> Assuming we concentrate on (1) for now .. (which for sure is
> by itself more than enough complexity ..)
Effectively a complex/nice objective by itself. OTOH, we might need
to look at what the core needs to provide to allow a tool to be
multi-threaded and understand the interactions between core and tool
in terms of locking.
>
> > 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?
Currently, the reader/writer lock protects the call to VG_(translate)
(and so all what is behind i.e. VEX, the translation table, ...).
I understand that the code translation is not a big part of the
cost, so using locking here might be the best approach.
Not too clear what would be the alternatives:
* a local translation table per thread ?
=> (what about memory ?)
* a lockless data structure ? (e.g. lockless hash table ?)
=> what about performance of the search ?
=> and we still have to avoid the below problem, i.e.
make a translation disappear when a thread is using it.
>
> 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?
So, the proto reader/writer locking for this might be the good approach.
Philippe
|