On Friday 01 July 2005 11:38, Mario Sergio Fujikawa Ferreira wrote: [snip]
> That does not protect against race conditions. If the > send_notification (emit()) thread is interrupted right in the middle of > the write(2) call, we will end up with another thread doing a write(2) > and another one overlapping is atomicity is not guaranteed. As per the > POSIX standard upholding, I am not seeing such atomicity guarantees > under Conectiva Linux 9 kernel 2.4.x series with Linuxthreads. It could > be just a problem with my development environment (which should not be > since I am able to reproduce this problem under Mandriva Linux) but we > should not rely on that but do take a safer approach right from the > start. Pipes are, through their file descriptors, a resource shared between processes as well as threads. You can be pretty sure that glibc is providing the atomicity guarantees required by POSIX with respect to this, as it tries hard to get these things right. You can therefore take it that there is no race condition in relation to different processes writing to the same pipe. As I said, you are technically right in the sense that POSIX only guarantees the position where different processes write to the same pipe, not where different threads within any one process write to the same pipe. Even if glibc were not to offer atomicity between threads (although it would have to work hard at not providing atomicity between threads if it is providing it between processes), I am pretty certain that this is not your problem (see further below). (It is difficult to see how interleaved data could cause a lock-up - note that write() itself is guaranteed to be thread safe.) [snip] > Okay, here is my theory from what I gathered from gdb. This is > just a theory. Others more experienced with {glib,gtk}mm inner workings > should know better. Well, under some irregular circunstances it is > possible to lock up all threads (including the main thread and the > controller thread for that matter) if a send_notification thread is > preempted in the middle of it's execution while holding the lock. If > the main/controller thread tries to use the send_notification (emit()), > it will end up waiting on that mutex. Dead lock. Any way, even if this > is not the case, I am experienced deadlocks with that approach. I think I can see where you are going wrong. You should not have the same thread both (a) calling emit() on the Glib::Dispatcher object (sending the notification) and (b) being the thread within which the Glib::MainContext polling the pipe for reading executes (and therefore in which the slot connected to the Dispatcher executes). You should normally only emit from a worker thread - ie a thread which is not the main thread (Glib::MainContext) within which Glib/GTK+ is executing. Otherwise you can get a deadlock. This deadlock does not arise as you suggest because of a recursive call to any mutex you use (if all you are doing is putting a mutex around the write call to the pipe then the same thread which is doing that write cannot at the same time also be trying to reacquire the mutex), but because the write is a blocking write and when any one thread is writing to the pipe, it cannot also be reading from it. You say you are using the Dispatchers heavily. If you are stuffing so much data into the pipe that it is full before it has a chance to be read by the next iteration through the main program loop (Glib::MainContext), then if the thread sending the notification is also the one which reads from it then it will block on the write for ever because the pipe can never be emptied. If you are emitting a signal in the same thread as the one in which you want the slot connected to it to execute (the main program thread), just use a plain sigc::signal0<void> object in those cases (reserve the Glib::Dispatcher for a case where a different thread is sending the notification). You can have a sigc::signal0<void> object and a Glib::Dispatcher object connected to the same slot, and because the slot will (if you adopt this approach) be executing in only the main program thread, you will need no mutexes for it. Chris. _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list