[interprocess] named_condition wait question
Hi,
I am using boost::interprocess::named_condition to synchronize 1-to-many
communication. The reading processes are waiting on a named_condition
that indicates the possibility to read. Problem is now that they wait
until doomsday if no one triggers notify. So they can't quit the reading
process themselves.
Now I am thinking about using timed_wait instead of wait. That means
checking some other exit-condition periodically. The question is now if
the reader can miss the notify while he is checking that exit-condition?
This is crucial to me because the readers have to notice new data in a
shared memory segment.
Thanks in advance.
Problematic code:
named_upgradable_mutex mtx;
named_condition cond;
{
sharable_lock
The reading processes are waiting on a named_condition that indicates the possibility to read. Problem is now that they wait until doomsday if no one triggers notify. So they can't quit the reading process themselves.
I always use a special "quit" message sent in the normal mechanism that it uses to send work. Also, I always advise waiting on a special "error" flag in addition to whatever you are really waiting for, when you block. That allows exceptions to always be able to un-stick the workers. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
My problem is that I can't kill the clients because their work() methods run as a boost::thread and they're stuck in the wait() call. So they don't reach this_thread::interruption_point(). That is correct behavior because in my application they have to wait until new data has arrived. But this prevents me from stopping them. Currently I am looking for a proper way to interrupt the wait() call. But if I use timed_wait() they possibly miss the notify() signal. Can you explain your use of an error flag? Thank you in advance. John Dlugosz wrote:
The reading processes are waiting on a named_condition that indicates the possibility to read. Problem is now that they wait until doomsday if no one triggers notify. So they can't quit the reading process themselves.
I always use a special "quit" message sent in the normal mechanism that it uses to send work. Also, I always advise waiting on a special "error" flag in addition to whatever you are really waiting for, when you block. That allows exceptions to always be able to un-stick the workers.
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
participants (2)
-
John Dlugosz -
Moritz