[c++-pthreads] thread-safety definition

[Mathieu Lacage]

On Thu, 2004-01-08 at 12:34, Dave Butenhof wrote:

> >1) "inside cancelation": This is basically ExitThread (win32 name). It
> >exists on all the platforms which support a form of threads or another I
> >know of. It semantics vary a lot from one platform to the other
> >unfortunatly. On win32, it will not invoke any thread-specific cleanup
> >handlers (neither C++ exceptions nor SEH are involved). On BeOS
> >(exit_thread), it will behave just like on windows. On POSIX
> >(pthread_exit) systems, it will invoke the thread-specific cancelation
> >handlers.
> >  
> >
> The term "cancellation" seems heavy here. This is just a voluntary 
> termination. But, yes, there are similar properties -- certainly from 
> the point of view of the rest of the frames on the call stack at the time.

Indeed. For a C++ POSIX binding, I would assume you might want to make
such a function throw an exception caught by the thread-creation
function to unwind properly the stack. Or is this some kind of wild
stupid idea ?

> >2) "outside cancelation": There are two kinds of "outside cancelation":
> >
> >	2.1) "async cancelation": The OS removes the thread from its list of
> >tasks to schedule and does nothing to cleanup the thread ressources.
> >This is the most extreme useless feature of a thread library. BeOS and
> >win32 provide it. POSIX does not provide it.

I should add: win32 (TerminateThread), BeOS (kill_thread).

> POSIX already defines "async cancel", as a mode where posting a cancel 
> to a thread will cause the cancellation to be delivered at any arbitrary 
> time supported by the OS and hardware. (Usually on the next clock tick, 
> though that's a "common implementation" rather than any rule or even 
> recommendation.)

OK. I guess this definition of "POSIX async cancel" was already
explained on the list before but I missed it. I believe this POSIX async
cancel is similar enough (at least, it feels as unsafe to use) to
"abort" that we could count it in section 2.1. What do you think ?

> "Cancellation" (both deferred and async) come from the Digital "CMA" 
> architecture (where it was called "alert"). The CMA concept derives from 
> a less structured (but fundamentally similar) capability in the SRC 
> research labs' Topaz thread package.

Do you know of other widely used system-level APIs which provide similar
features ?

> >Definition "Posix thread-safety":
> >---------------------------------
> >A library is "posix thread-safe" if it is thread-safe and
> >defered-cancelation-safe.
> >
> I wouldn't tack cancel-safety onto thread-safety so intimately, although 

I used the POSIX name because I thought it was the only widely deployed
system which provides this service. Maybe we should rename this to
"strong thread-safety". Maybe "defered-cancel thread-safety" ?

> (Async cancel is an oddity; there are, and should be, very few 
> async-cancel-safe functions. Async-cancel regions of code cannot 
> accomodate resource acquisition or release of any sort, as the recovery 
> code is generally unable to determine the state of the resource.)

Yes. This is why I don't feel it's necessary to discuss it further since
so little code will be concerned with it, we can altogether not deal
with it for most C++ libraries.

> Nevertheless, it's quite reasonable to write a "thread-safe" special 
> purpose application routine that doesn't deal with cancellation simply 
> because the designer KNOWS that a thread running that code cannot be 
> cancelled. One might even make this choice within in a general purpose 
> library in some cases -- say, for a daemon thread that could never run 
> application code nor be identified to the application, and that 
> therefore cannot be cancelled.

Yes. Exactly. I have written a lot of code like that. The core C++
threaded code is hidden far away from the user which cannot therefore
"posix-defer-cancel" it. It can't even ever get the C++ exceptions since
they are catch (...) and transformed into C error codes.

As a conclusion to these (tentative) definitions, I believe the purpose
of this mailing list is to find a solution to develop "defered-cancel
thread-safe" C++ libraries: simple "thread-safe" libraries do not
require special attention. If everyone could agree to the statement
above, it would probably make the discussion more productive: other
threading models which do not support async cancelation are of no
interest to the discussion and can be forgotten.

If people agree on this statement, the only issue I can see which
delimits the design space for the solution to this problem is whether or
not you wish to allow the C++ library calling into C code (which uses
pthreads) and/or allow C code to use the C++ library (which uses our C++
threading solution).

Maybe it would help to consider the two cases separatly and try to
figure out what requirements each case creates:
	1) C++ library calls C++ code and is called by C++ code.
	2) C++ library calls into C code.
	3) C code calls C++ library.

The hard part seems to be 2) and 3) where, if you use exceptions to
propagate a cancel operation from either a cancelation point or a
pthread_exit call, you need to correctly handle the registered
cancelation handlers _and_ the C++ catch blocks in the right order. That
seems pretty hard (ie: impossible) to me, being just a _user_ of thread
libraries.

If people are not interested in 2) and 3) and just want to design a
solution for 1), then I think it will make the discussion more
productive to acknowledge it.

Mathieu
-- 
Mathieu Lacage <mathieu.lacage at sophia.inria.fr>