pthread and Win32 Threading Questions
John Hickin
The pthread API uses absolute timeouts (as parameter to pthread_cond_timedwait)
while the Win32 API uses relative timeouts. In pthreads it is suggested that
the absolute time now+delta may serve as a relative timeout interval of delta.
I am worried, however, that changing the system time may cause such timeouts to
fire early. Can this indeed happen?
pthreads and C++ don't seem to get along too well. I believe that my threads
must run with cancellation disabled for fear that the stack won't be unwound
when if the thread is terminated. Is there any other way to cope?
--
John D. Hickin Nortel Technology, Montreal, Quebec
(514) 765-7924 hic...@nortel.ca
Dave Butenhof
John Hickin wrote:
> The pthread API uses absolute timeouts (as parameter to pthread_cond_timedwait)
> while the Win32 API uses relative timeouts. In pthreads it is suggested that
> the absolute time now+delta may serve as a relative timeout interval of delta.
> I am worried, however, that changing the system time may cause such timeouts to
> fire early. Can this indeed happen?
Yes, it can happen. The problem is that, while an absolute time can be used "to
represent" a relative time (or vice versa), requiring the program to perform the
conversion means that the system has no way to determine which was intended.
A future amendment to POSIX 1003.1 (1003.1j) provides a way to specify a POSIX
clock ID for a condition variable, and a new standard (though optional) POSIX
clock that essentially is a relative time. (CLOCK_MONOTONIC, which is an
"absolute" clock that cannot be changed.) All of the good reasons for specifying
condition waits as absolute rather than relative times remain -- the monotonic
absolute clock, however, provides a way to retain those advantages while also
allowing the program to make their relative waits independent of system clock
adjustments.
> pthreads and C++ don't seem to get along too well. I believe that my threads
> must run with cancellation disabled for fear that the stack won't be unwound
> when if the thread is terminated. Is there any other way to cope?
On some systems, cancellation will not run object destructors. It does work,
however, at least on Solaris and Digital UNIX, and most likely others as well
(though I don't recall any definitive reports).
It is true that there's no portable standard mandating that sort of integration,
since ANSI C++ says nothing about threads and POSIX (and UNIX98) say nothing about
C++. Nevertheless, any vendor that doesn't make them work together is under a
silly illusion that either C++ programmers don't care about concurrency, or that
thread programmers don't care about C++. Correct their misunderstandings, firmly
but gently. ;-)
/---------------------------[ Dave Butenhof ]--------------------------\
| Digital Equipment Corporation bute...@zko.dec.com |
| 110 Spit Brook Rd ZKO2-3/Q18 http://members.aol.com/drbutenhof |
| Nashua NH 03062-2698 http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----------------[ Better Living Through Concurrency ]----------------/
Steve Watt
In article <355740B6...@zko.dec.com>,
Dave Butenhof <bute...@zko.dec.com> wrote:
>John Hickin wrote:
[ snip ]
>> pthreads and C++ don't seem to get along too well. I believe that my threads
>> must run with cancellation disabled for fear that the stack won't be unwound
>> when if the thread is terminated. Is there any other way to cope?
>
>On some systems, cancellation will not run object destructors. It does work,
>however, at least on Solaris and Digital UNIX, and most likely others as well
>(though I don't recall any definitive reports).
First: I apologize for my ignorance, I don't know C++. And only a little
bit of Java. Lots 'o C, though.
How does it decide what objects need to be destroyed? Aren't objects
allocated out of the heap, where all threads in a process could use them?
Does the implementation have hooks in the compiler to know which objects
need destruction, and which don't?
[ snip C++ vs pthreads not in Unix98 or any current POSIX draft ]
Is there work going on in this area? Seems like something that needs
to be standardized.
--
Steve Watt KD6GGD PP-ASEL-IA Packet: KD6GGD @ N0ARY.#NOCAL.CA.USA.NA
ICBM: 121W 56' 58.1" / 37N 20' 14.2" Internet: steve @ Watt.COM
Free time? There's no such thing. It just comes in varying prices...
John D. Hickin
Steve Watt wrote:
> How does it decide what objects need to be destroyed? Aren't objects
> allocated out of the heap, where all threads in a process could use them?
> Does the implementation have hooks in the compiler to know which objects
> need destruction, and which don't?
>
The objects which should be destroyed are those ones that exist in any
active stack frame of the thread being cancelled. This is done as a
matter of course when a block is exited normally or via an exception.
The object destruction is carried out by the appropriate destructor
function associated with the class of each object.
It is possible for a pthreads implementation to unwind the stack if
somehow it could inject a call to throw an exception when cancellation
is observed to be pending at a cancellation point (the case of async
cancellation is problematic; I'm not sure that the stack could be
reliably unwound without unduely penalizing the normal execution case).
The documentation that I have says that thread cancellation is
equivalent to calling pthread_exit; unfortunately the doc for
pthread_exit says nothing about C++ either. I'm thinking that a C++
compiler could generate code to set up an exception handling frame
before it calls your thread function as in:
void* crt( void(*func)(void*) , void* calldata ) {
try { return func(calldata); }
catch(...) { return (void*)-1; }
}
and to implement pthread_exit() as throwing a PthreadExitException (this
is a hypothetical exception class).
This looks fine in theory but in practice it I think that it requires
the c and c++ compilers to generate compatible code in the sense that
you can unwind the stack of a c function as well (i.e., the unwind code
can determine whether or not the stack frame belongs to a c- vs. a
c++-compiled function).
Dave Butenhof
Steve Watt wrote:
> In article <355740B6...@zko.dec.com>,
> Dave Butenhof <bute...@zko.dec.com> wrote:
> >John Hickin wrote:
> [ snip ]
> >> pthreads and C++ don't seem to get along too well. I believe that my threads
> >> must run with cancellation disabled for fear that the stack won't be unwound
> >> when if the thread is terminated. Is there any other way to cope?
> >
> >On some systems, cancellation will not run object destructors. It does work,
> >however, at least on Solaris and Digital UNIX, and most likely others as well
> >(though I don't recall any definitive reports).
>
> First: I apologize for my ignorance, I don't know C++. And only a little
> bit of Java. Lots 'o C, though.
>
> How does it decide what objects need to be destroyed? Aren't objects
> allocated out of the heap, where all threads in a process could use them?
> Does the implementation have hooks in the compiler to know which objects
> need destruction, and which don't?
This is based on CODE scope, not some sort of "object scope" (there's no such
concept). Heap objects aren't "destructed" until they're deleted. So if you have
stack-based pointers to heap objects, they won't (necessarily) be destroyed
automatically when the thread is cancelled. That's correct -- since it's a heap
object, other threads (at least in theory) have access.
If the object is really private to the thread, you can use various types of
"helper classes" (smart pointer objects are one example) that ARE stack objects,
which will be destroyed by any exit (exceptional or otherwise) of the containing
scope, and will as a consequence destroy the object(s) to which they point. C++
lets you perform all sorts of cute & awesome (and often confusing) tricks.
> [ snip C++ vs pthreads not in Unix98 or any current POSIX draft ]
>
> Is there work going on in this area? Seems like something that needs
> to be standardized.
Yep. Just a matter of figuring out which standards group wants to get the ball
rolling. Nobody's stood up to volunteer. POSIX is unlikely, since there's no C++
anywhere under POSIX. ANSI C++ has presumably got enough to worry about so far
just in getting out a C++ standard. They're certainly the most likely people to
worry about making C++ thread-safe.