cancel wait on condition variable?

[Christopher Pisz]

I don't think there is any cancel mechanism, only signal. So, what do I do in the following scenario (I try to describe best I can)?

There is a blocking call in existing code that expects a value to be returned for a given string.

There is an asynchronous networked library that can get that value for the given string.

So, I created a condition variable in the former that gets signaled when a map is updated in the latter.

Problem is if I get disconnected while waiting, I don't want the calling thread to wait forever and the request for the data over the network has already fired so it is gone.

I think I have to implement some kind of reconnect mechanism, signal the condition variable and then not only see if the string is on the map, but also whether or not we are connected. I'm not sure.

What tools do I have in my tool box for this scenario?

[Paavo Helde]

The condition variable is the least of your problem, when you want to
cancel it you just set a cancel flag and notify the condition variable.
When the waiting thread returns from the wait on a condition, it must
study the state (of the data protected by the associated mutex) anyway
because spurious wake-ups are possible. So studying the cancel flag is
just another check for its state like any other.

The hard part is to get the cancel action triggered when the network
goes down, anything related to the network/distributed computations is
very hard to get working correctly in all situations. But I believe this
is something what should be taken care of by your "asynchronous
networked library".

[Scott Lurndal]

Christopher Pisz <christo...@gmail.com> writes:
>I don't think there is any cancel mechanism, only signal. So, what do I do in the following scenario (I try to describe best I can)?
>
>There is a blocking call in existing code that expects a value to be returned for a given string.
>
>There is an asynchronous networked library that can get that value for the given string.
>
>So, I created a condition variable in the former that gets signaled when a map is updated in the latter.
>

Add a "terminate" flag and check it when the condition variable wait
function returns.

#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))

void
CLASSNAME::thread_run_method(void)
{
ignore_signals();
g_lock.lock();
while (!ACCESS_ONCE(g_terminate)) {
g_fifoevent.wait(&g_lock);
if (ACCESS_ONCE(g_terminate)) break;

c_dlist_iterator di(&g_upstream_queue);
while (di.next()) {
s_wqe *wqep = (s_wqe *)di.curr();

process_message(wqep->f_core, wqep->f_message);
wqep->remove();
delete wqep;
}
}
g_lock.unlock();
}


(g_fifoevent is an instance of c_condition, an abstraction of the pthread_cond_*
functionality, g_lock is an instance of c_lock, an abstraction of pthread_mutex_*).

[Chris M. Thomasson]

Add on, or tweak something to the existing shared conditional state,
that includes the ability to cancel according to your needs. Keep in
mind that the mutex-condvar relationship is atomic wrt waiting. You can
set an aspect of your shared state to "cancel mode", and signal
something. Or heck, broadcast (notify_all) that state mutation to an
entire thread pool.

Include reaction code in the worker threads that knows what to do after
a cancel state is noticed, fin?

;^)