Right, sorry about that.
> A little clarification: The non-thread-safety include the initial mapping > operation, that is, you probably need > a per-object lock around mapObject > and sync(). I tried this. I overrode mapObject in my Config class and guarded the passthru call to eq::Config::mapObject() with a mutex. I then also guarded the call to sync() with a mutex. I'm still ending up with a deadlock unless I avoid the sync() iff the version is co::VERSION_FIRST. Either way, there should be no way that more than one thread are attempting to sync() the Distributables that I gave in node.cpp, right? They are only being created and then mapped in the next instruction. I'm never trying to do anything with them after that point. Or is it that mapObject will also internally try to sync the object? If that is the case it could conflict with the worker thread also attempting to sync it. In any case, a mutex didn't seem to do anything. This can be verified by defining a co::base::Lock member variable for each Distributable. Then, in the Worker thread, I have co::base::ScopedMutex<> _mutex(slave->_lock). The worker thread in node.cpp will still deadlock. -- View this message in context: http://software.1713.n2.nabble.com/Sending-packets-containing-std-wstring-tp6845178p6959298.html Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
