Re: [PATCH v2] Make xmalloc and xrealloc thread-safe
- From
Shawn Pearce <spearce@spearce.org>
- Date
- Apr 7, 2010, 14:30 UTC
- Message-ID
- <w2kec874dac1004070730rd1e5c149x88a7d6b4b649792f@mail.gmail.com>
- In-Reply-To
- <alpine.LFD.2.00.1004070859540.7232@xanadu.home>
On Wed, Apr 7, 2010 at 6:17 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> Maybe. That would in fact just mean pushing the double mutex issue into > the pthread emulation instead of having it outside it. This would > impact performances for all mutexes although only one instance of them > currently require a recursive behavior.
But we know when the mutex is created whether or not it needs recursive support. So in the Windows emulation we may need to allocate two mutexes for each pthread_mutex_t storage-wise, but we don't necessarily need to use that owner thread mutex on every lock/unlock request, do we?
Show 6 quoted lines
> Yet, the memset() issue comes up only because pthread_t is meant to be > an opaque type. The only information we would need here is the actual > thread ID as returned by gettid() on Linux or GetCurrentThreadId() on > Windows, and then the read_mutex_owner could be a simple atomically > modifiable integer. But what about other pthread-capable non Linux > systems?
Indeed. If Windows threads are atomic words, then actually you don't need that double mutex in the emulation layer, and can instead use the atomic word to determine ownership. Which makes this entire debate somewhat moot, doesn't it?
Use a standard recursive pthread mutex, and implement recursive support in the emulation layer using the atomic word holding a GetCurrentThreadId() result. We don't need to worry about how pthread_t is stored on any particular system, the thread library will do it for us.
-- Shawn.