Re: next round: glib thread safety proposal

[Jeff Garzik <jgarzik pobox com>]

Sebastian Wilhelmi wrote:
> > > ok, I read the thread and if I got it right, it basically said, there
> > > might be SMP platforms without hardware cache coherence, that might fail
> > > to work correct for the above. (but nobody actually  named such, apart
> > > from virtual shared mem systems). So I made it lock the mutex everytime.
> > 
> > Yeah, I don't know how much of a real problem this is.
> > Reading through the Intel hardware specs for MP machines,
> > it looks like it can't happen there. (Assumming the processor,
> > as opposed to the cache, never makes speculative reads for
> > "random" bits of memory)
> 
> Anyway, it surly is better to be on the safe side, even if it in our case
> forces us to include pthread.h into glib.h. A possible cure is of course
> the split of the glib files.

Take a look at my half-baked implementation.  Check out
GLIB_1_1_4_THREADS branch.  It includes pthread.h the Right Way(IMHO).
I didn't get very far with this, just made a few modules thread-safe.


> Ah, this brings us to the point, you so far avoided to comment on: what
> about thread specific data? It would be nice to have (even though, to be
> honest, it is most certainly not much faster than mutexes).

Is this an issue?  I've always handled this with logic.  If a piece of
data doesn't belong on the thread's stack, I stick it into the main
dataspace while ensuring only that particular thread "knows" about it.

	Jeff