[Libsigcx-main] Re: [sigc] Re: [gtkmm] libsigcx and gtkmm 2.4

[Daniel E. <dan...@gm...>]

Am So, den 13.06.2004 um 11:39 Uhr +0200 schrieb Christer Palm:

> > Even if it does this you still need mutex locking to protect
> > the memory being shared (ensuring that event A happens after event B is
> > not enough due to the way modern hardware works; you definitely need
> > memory barriers too).
> > 
> 
> Synchronous signals _does_ use a mutex behind the scenes to implement 
> the locking. Not that, AFAIK, mutexes does anything more than ensuring 
> that event A happens after event B.

The problem is you need to lock before the data is being written.  And
mutexes don't ensure that event A happens after event B.  Mutexes ensure
that read/write A and read/write B don't happen at the same time, _and_
they issue memory barrier instructions to ensure memory visibility.

> > Also, you can always use plain Glib::Dispatcher in conjunction with a
> > Glib::Mutex to pass data around.  This way you're forced to think about
> > the locking which is IMHO a good thing.
> > 
> 
> IMHO, this is like saying that function arguments are unnecessary, 
> because you could always use global variables to pass data around.

Remember, we're talking about thread synchronization.  This is not
something to be taken lightly.  Also note that nobody said that the
locked data has to be global; you can easily store it in an object
somewhere appropriate, or even put it into a queue.

--Daniel