[llvm-commits] VM hooks when locking

[Nicolas Geoffray]

Owen Anderson wrote:
>
> On Jul 30, 2009, at 11:55 PM, Nicolas Geoffray wrote:
>> So In my case (vmkit), I don't really care about /what/ is being locked
>> on. All I need is the information that the thread /is/ blocked. I
>> understand that for a debugging/monitoring/whatever system, it would be
>> nice to know /what/, but that demands a more high-level solution.
>
> OK, but you're likely to get a bunch of false positives for this. 
>  Locks are (now) acquired in the process of type construction and 
> constant creation, which happen all over the place, assuming you're 
> running in multithreaded mode.

I can live with that :) Actually, vmkit already lives with it, as locks 
are already taken all over the place. Actually, the best place to add 
the hooks would be in the pthreads implementation, where the thread 
/knows /it will block. But I don't think I can do that :)

>
>> The only places where the VM-provided functions must be called is when
>> there are chances the thread will be blocked. I believe the only place
>> in llvm where a thread may be blocked is when it calls the
>> pthread_mutex_lock, and that is only in Mutex.cpp. I believe the
>> recursive and normal mutexes share the same function.
>
> Nope, see lib/System/RWMutex.cpp.  They don't share an implementation.

Ah, I did not know that file. So yes, all places where something that 
may block is called needs to call the hooks.


Another solution would be to only call the hooks with the JIT lock. The 
other locks are all internals and won't block the threads too long. 
Would you prefer that solution? That requires to track all places where 
the JIT lock is used, so it's more error-prone.

Nicolas

>
> --Owen
> ------------------------------------------------------------------------
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>