Re: Glib::Dispatcher1<T>

[Chris Vine <chris cvine freeserve co uk>]

On Saturday 20 January 2007 13:07, Daniel Elstner wrote:
[snip]
> I don't get it.  Why should there be a need for any synchronization
> beyond the memory barrier when passing pointers to custom types?  Note
> that I'm proposing to stream the data argument through the pipe.  Some
> pseudo code:
>
> send_notification(...)
> {
>    DispatchNotifyData data (dispatcher, this, arg_union);
>
>    if (is_dynamic)
>      // Lock and immediately unlock mutex to issue a memory barrier.
>      Glib::Mutex::Lock lock (mutex_);
>
>    write(fd, &data, sizeof(data));
>    ...
> }
>
> receive_notification(...)
> {
>    DispatchNotifyData data;
>
>    read(fd, &data, sizeof(data));
>
>    if (is_dynamic)
>      // Sync with memory barrier in send_notification().
>      Glib::Mutex::Lock lock (mutex_);
>
>    data.dispatcher->emit_signal(data.arg_union);
>    ...
> }
>
> > Are you going to put a mutex around the argument in the sending and
> > receiving thread?
>
> Only for the pointer specializations (and not really *around* the
> read/write, I got that wrong in my proposal mail).  And even for pointer
> types this will be only the default behavior.  If you know what you're
> doing (e.g. when passing a pointer to static data), you may disable the
> extra lock/unlock.

I see, that looks good, except that the fact that data are static doesn't make 
them automatically visible (possibly some particular implementations do, I am 
not sure) - two threads can see different values for static data if the data 
have recently been modified.  But data passed by value over the pipe are as 
you say entirely safe.  The point is not whether data are allocated on free 
store (if that is what you mean by dynamic)  but whether they require 
dereferencing to address objects in memory not passed by value.

On a completely different point, also applicable to Glib::Dispatcher: the 
Posix standard guarantees atomic writes to pipes between different processes 
where the data is PIPE_BUF or less in size, but not between different threads 
in the same process.  I agree that an implementation would have to work hard 
not to have atomic writes between threads if it does so between processes, 
but it isn't formally guaranteed.  If you were worried about it you could put 
a mutex around the call to write().  (I would not be worried if I were using 
Linux.  I could not hazard a guess about other Unix-type OSs.)

Chris