Re: making GStaticMutexes faster
- From: Sebastian Wilhelmi <wilhelmi ira uka de>
- To: Sander Vesik <Sander Vesik Sun COM>
- Cc: gtk-devel-list gnome org
- Subject: Re: making GStaticMutexes faster
- Date: Thu, 10 May 2001 14:07:38 +0200
Hi Sander,
> > I think "cache coherence" is a topic, not a particular property...
> >
> > The particular property you are proposing relying on is if processor
> > #1 writes location A and then location B, then another processor will
> > never see a write to location B then a write to location A.
> >
> > (Since the writes are here separated by a function return it is
> > pretty unlikely that instruction reordering would cause problems,
> > so it probably is mostly a question of cache behavior, yes.)
> >
>
> Well, modern RISC processors aren't really under pretty much any
> constraints to re-ordering writes. Unless you use memory barriers
> and/or special setup in page tables.
Write reordering isn't a problem here, because when creating the mutex this is
protected by another mutex, which also acts an a memory barrier:
GMutex *
g_static_mutex_get_mutex_impl (GMutex** mutex)
{
GMutex *new_mutex;
if (*mutex)
return *mutex;
g_mutex_lock (g_mutex_protect_static_mutex_allocation);
if (!(*mutex))
new_mutex = g_mutex_new ();
g_mutex_unlock (g_mutex_protect_static_mutex_allocation);
/* No problems with write reordering, as between here and the creation
of new_mutex is a memory barrier */
*mutex = new_mutex;
return *mutex;
}
So the only issue is indeed cache coherency. See my other reply as well.
Bye,
Sebastian
--
Sebastian Wilhelmi
mailto:wilhelmi ira uka de
http://goethe.ira.uka.de/~wilhelmi
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]