[Ace-users] [ace-users] detach ACE_Thread
jwillemsen at remedy.nl
Tue Dec 18 13:16:25 CST 2007
If you consider to make patches, take the x.6.2 version, the threading code
has been cleaned up in that release
> -----Original Message-----
> From: ace-users-bounces at cse.wustl.edu [mailto:ace-users-
> bounces at cse.wustl.edu] On Behalf Of Andriy Gapon
> Sent: Tuesday, December 18, 2007 5:06 PM
> To: Douglas C. Schmidt
> Cc: ace-users at cse.wustl.edu
> Subject: Re: [ace-users] detach ACE_Thread
> on 17/12/2007 15:07 Douglas C. Schmidt said the following:
> >> Some questions:
> >> 1). I can not seem to find anything similar to pthread_detach() in
> >> ACE_Thread/ACE_Thread_Manager interface. Does ACE provide such
> >> capability at all ?
> > No, it doesn't (yet).
> >> 2). Assuming an answer to the previous question would be "no", is
> >> a way I could call pthread_* functions directly to "hack" to get
> what I
> >> want and not confuse ACE thread management ?
> > It seems to be that a better way to handle this would be to enhance
> > ACE_Thread_Manager so it supports a detact() method that does what
> > describe above, e.g., call pthread_detach() on platforms that support
> > it and also update the internals of the ACE_Thread_Manager so that
> > it'll update its internals.
> yes, it would be great to write this, but I am not sure if I could
> understand all the internal code, especially the variations for
> different platforms.
> Unfortunately I am short on time now, so maybe some time later.
> Just a small note for now: it is a very bad idea to simply call
> pthread_detach on a THR_JOINABLE thread created via ACE_Thread_Manager.
> First, some resources within the manager will not be cleaned up anyway
> (some data will be preserved there for a possible future join). Second,
> if the thread id is reused for another thread the manager can become
> confused and a deadlock can happen at the very least. This can be
> observed at least on 2.6.19 linux kernel where a thread id is re-used
> very quickly after thread termination (underlying implementation can do
> it because the thread became detached). (This happens because it is
> assumed that pthread_join on a terminated thread is non-blocking and
> quick, so it is done without releasing a mutex, but it turns out that
> the thread is not terminated it just re-used the id).
> Using ACE_Thread static methods for thread management is friendlier to
> pthread_detach, but there are other shortcomings with that.
> P.S. the described above issue with deadlock makes me wonder if
> ACE_Thread_Manager is immune to thread id re-use by underlying pthread
> library if joinable threads are created and terminated but join is
> called some time later.
> Andriy Gapon
> ace-users mailing list
> ace-users at mail.cse.wustl.edu
More information about the Ace-users