On 11/25/07, Ion Gaztañaga <igaztanaga@gmail.com> wrote:

Stefan Arentz escribió:

...

I checked out boost trunk from svn and tried to compile a simple boost.interprocess example. Unfortunately it fails at a rather unexpected place:

% c++ doc_message_queueA.cpp -Itrunk -o doc_message_queueA % ./doc_message_queueA Assertion failed: (res == 0), function lock, file trunk/boost/interprocess/sync/posix/interprocess_mutex.hpp, line 116. zsh: abort ./a

The error code is 22, EINVAL.

I'm on OS X 10.5.1, maybe that is too new, or not yet tested?

It is not tested but your problem and another problem reported a couple of weeks ago are pretty strange. If Leopard now offers process-shared posix mutexes and native shared memory, in theory Interprocess code should work without problems, just like other Unixes, but I don't know what's happening.

I don't have access to the OS so I'll need some help to fix these issues. Meanwhile, try to undef BOOST_INTERPROCESS_POSIX_PROCESS_SHARED define <boost/interprocess/detail/workaround.hpp> line 21. This will avoid native process-shared mutexes and conditions and Interprocess will work as in Mac Os 10.4

Thanks Ion. That did the trick. I'll check if Leopard actually has process-shared mutexes. I have another problem now. I am trying to create a simple cross-process consumer/producer example based on the doc_message_queue*.cpp examples. My producer looks like this: message_queue mq(create_only, "message_queue", 3600, sizeof(int)); for(int i = 0; i < 3600; ++i){ std::cout << "Publishing " << i << std::endl; mq.send(&i, sizeof(i), 0); sleep(1); } And the consumer like this: message_queue mq(open_only ,"message_queue"); unsigned int priority; std::size_t recvd_size; for(int i = 0; i < 10; ++i){ int number; mq.receive(&number, sizeof(number), recvd_size, priority); std::cout << "Consumed " << number << std::endl; } When I start the producer it starts filling the queue. When I run the consumer multiple times it first quickly grabs 10 numbers in the queue until it is empty and then i see the rest appear every second. So far so good. The problem is that when I kill or Control-C the consumer that the producer stops. I assume that this is because some lock is held by the consumer and the producer is waiting for it. Is there a way to release these locks when the consumer is killed? Or a way to detect this, so that I can release them manually or so? S.

One idea could be that when a process obtains the mutex it stores its pid in it. Another process can then - if it takes too long to take the lock - check if there exists such a pid and if not just forcibly take the lock itself. Of course this assumes that locks are never held for "a long time", and is quite easily considered a horrible solution... But it may well work in many situations. Lars Ion Gaztañaga wrote:

Stefan Arentz escribió:

...

The problem is that when I kill or Control-C the consumer that the producer stops. I assume that this is because some lock is held by the consumer and the producer is waiting for it.

Is there a way to release these locks when the consumer is killed? Or a way to detect this, so that I can release them manually or so?

Ufff... Signals are quite difficult to handle. You will have the same problems with other process-wide resources, like files. I can't think about any reliable solution right now. We would need to add cancellation to process-shared mutexes and that does not seem easy. The only think I can think is handling the signal (but avoiding ending the process) and setting a global variable that is checked by other threads. You could only use timed functions send/receive functions that check that global variable. If the variable is set, an exit from process cleanly (exit from non-main threads). If you only use the main thread, throw an exception when the global variable is set. Not very clean, but I think it's the only way.

Regards,

Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Lars Hagström wrote:

How about adding (as an option?) this kind of behaviour to the emulated mutexes in interprocess?

I could provide a macro to use emulated mutexes/conditions instead of native ones.

The Posix mutexes I assume guarantee some kind of robustness, so that if a process crashes its locks are released. by adding the below behaviour we get reasonably close to that behaviour for the emulated mutexes.

I don't Posix mutexes provide much robustness but they provide much higher performance, since emulation is based on atomic compare and exchange plus spin-waits. Anyway, I definitely need some help on Mac OS 10.5. I don't know if anyway has used those process-shared mutexes in practice and if they work at all.

Cheers Lars

Regards, Ion

On Tue, Nov 27, 2007 at 08:25:27PM +0100, Lars Hagström wrote:

Hmm, I've been thinking about this a little bit more, and I've more and more started to like the idea (not for its beauty, but more for its practicality)...

I think this approach is a bad idea. Even if the application itself does not hold the mutex for a long time (measured in CPU time), it may be preempted and/or stopped for arbitrary amounts of time (eg. think swapping). If this happens after it has acquired a mutex, then this scheme will break.

Lars Hagström wrote:

...

Of course this assumes that locks are never held for "a long time", and is quite easily considered a horrible solution... But it may well work in many situations.