Re: [PATCH v2] Make xmalloc and xrealloc thread-safe

[Shawn Pearce <spearce@spearce.org>]

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?

> 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.