Concurrent Containers

[Ian Collins]

Let's suppose my company has an engine which executes SQL from backing
federated data stores, including relational databases of many flavors,
flat files, etc. Let's further suppose that the user wants a "cancel"
button. This should stop the engine processing so that the CPU,
memory, disk, network, and other hardware resources are available to
run another SQL which the user may type in immediately following a
cancel. How would you do this? Or is this one of those rare times
cancel is a good idea?

[slight delay in responding due to a rather large earthquake!]

Cancellation has to be designed in up front. Any form of asynchronous
cancellation is fraught with problems unless the design is async-cancel
safe. It's akin to design exception safe code, only harder. Some run
time environments will clean up, others will not. Nothing is guaranteed
by the standard.

If possible, your loop should include cancellation points so it can
terminate cleanly. Better still use some form of explicit termination
of loops ( while (keep_going) {..} ).

I was thinking about it more, and thought of another couple of angles.
You could wrap the standard library to provide cancellation points
(eww).

Or test for cancellation if your implementation supports it (POSIX
pthread_testcancel() for example).

Alternatively, thread cancellation without timed waits or wrapping the
std might be more maintainable if you keep the number of effective
cancellation points to a bare minimum. Specifically, you don't
sprinkle "if (stopped()) throw stop_exception();" everywhere, and
instead keep the number of effective cancellation points to a very
small number. However, it just seems to be another way to sacrifice
responsiveness (larger blocks of uninterruptable work, like timed
waits) for better maintainability (like always-timed waits).

Everything is software is a compromise! You have to trade
responsiveness with the complexity of being async-cancel safe.

 

[Ian Collins]

Joshua Maurice wrote:

[... cancellation ...]

You should google pthread_cancel_e and/or pthread_exit_e.

Hth.

From what I understand, pthread cancellation is a mess. Besides, I
thought we were talking about cancellation in C++0x, not POSIX.

It isn't a mess, just poorly understood. I haven't studied cancellation
in C++0x, but with POSIX you can treat cancellation handlers as you
would any other resource and used them to make your classes (reasonably)
cancellation safe.

 

[Branimir Maksimovic]

Joshua Maurice wrote:

[... cancellation ...]

You should google pthread_cancel_e and/or pthread_exit_e.

Hth.

From what I understand, pthread cancellation is a mess. Besides, I
thought we were talking about cancellation in C++0x, not POSIX.

It isn't a mess, just poorly understood. I haven't studied
cancellation in C++0x, but with POSIX you can treat cancellation
handlers as you would any other resource and used them to make your
classes (reasonably) cancellation safe.

How you could make synchronous cancellation safe, eg following:

void f()
{
A a; // a is class that allocates some memory in constructor
a->f();
}

In my understanding you can't make asynchronous cancellation safe
in any way. Synchronous you can, but all your classes would
be riddled with pthread_cleanup_push/pop and I don't know
how to solve that cleanly.

Greets, Branimir

 

[Alexander Terekhov]

Branimir Maksimovic wrote:
[...]

How you could make synchronous cancellation safe, eg following:

void f()
{
A a; // a is class that allocates some memory in constructor
a->f();
}

??? What are the cancellation points?

Did you make f()/a() exception safe?

In my understanding you can't make asynchronous cancellation safe
in any way.

Wrong. You simply code inside the corresponding async_cancel {} region a
sync_cancel {} and/or no_cancel {} sub-region if you want to create a
nested async_cancel-unsafe sub-region inside async_cancel {} region. Is
it really so hard to grok?

async_cancel{ // may throw cancel_e asynchronously

. . .

sync_cancel { // may throw cancel_e synchronously

. . .

no_cancel { // may not throw cancel_e at all

. . .

async_cancel{ // may throw cancel_e asynchronously

. . .

}
catch(cancel_e) { // may not throw cancel_e at all

. . .

}

}

async_cancel { // may throw cancel_e asynchronously

. . .

}

no_cancel { // may not throw cancel_e at all

. . .

}

. . .

} // may throw cancel_e synchronously

. . .

} // may throw cancel_e asynchronously

// DEFAULT: may throw cancel_e synchronously

. . .

Hth.

regards,
alexander.

 

[Branimir Maksimovic]

Branimir Maksimovic wrote:
[...]

How you could make synchronous cancellation safe, eg following:

void f()
{
A a; // a is class that allocates some memory in constructor
a->f();
}

??? What are the cancellation points?

Did you make f()/a() exception safe?

I didn't thought about that, but say yes.
My point was in order to make some code cancellation safe
you have to change implementaton of A()/f()

Wrong. You simply code inside the corresponding async_cancel {}
region a sync_cancel {} and/or no_cancel {} sub-region if you want to
create a nested async_cancel-unsafe sub-region inside async_cancel {}
region. Is it really so hard to grok?

async_cancel{ // may throw cancel_e asynchronously

Well, then we are speaking of different things. I meant POSIX
cancellation, this is something new for me.


regards, Branimir.

 

[Alexander Terekhov]

Branimir Maksimovic wrote:
[...]

Well, then we are speaking of different things. I meant POSIX
cancellation, this is something new for me.

async_cancel {

}

in POSIX terms is

int oldtype;
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &oldtype); {

} pthread_setcanceltype(oldtype, &oldtype);

regards,
alexander.