RE: [boost] Re: boost.threads

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-08-09 16:31:43

At 10:06 PM 8/8/2001, Darryl Green wrote:
 >
 >
 >> -----Original Message-----
 >> From: Beman Dawes [mailto:bdawes_at_[hidden]]
 >> Sent: Wednesday, 8 August 2001 11:41 PM
 >> To: boost_at_[hidden]
 >> Subject: RE: [boost] Re: boost.threads
 >>
 >>
 >> At 01:08 AM 8/8/2001, Darryl Green wrote:
 >>
 >>  >...
 >>  >Beman suggests that another thread should expect
 >>  >evil consequences if it tries to access the stack
 >>  >of a terminated thread and that this is similar
 >>  >(identical) to what will happen in a single
 >>  >threaded environment if an attempt is made to
 >>  >access the stack of a function that has returned.
 >>  >This is true, but it is relatively easy to avoid
 >>  >in the single threaded case. It is very hard to
 >>  >avoid unknowingly making a similar error in a
 >>  >multi-threaded program.
 >>
 >> Can that really be said as a blanket statement?
 >>
 >> I can easily think of cases where it would be true, mostly involving
 >> designs with dynamically changing numbers of threads.
 >>
 >> But other designs involve a small number of always present (during
 >> processing of work) threads with very fixed roles.  They are
 >> all started
 >> initially, process for awhile, and then terminate together.
 >> If one of them
 >> went away unexpectedly during the processing phase, it would mean the
 >> program was totally trashed.  In my own case, these are mostly batch
 >> processing programs not normally subject to outside disturbance.
 >>
 >> We might want to warn against the practice of sharing (via
 >> pointers and
 >> references) automatic storage objects, but we would need to
 >> be specific as
 >> to when it is a problem.
 >>
 >> --Beman
 >
 >I agree. My concerns are partly about highly dynamic environments and
 >also about environments with relatively large numbers of threads that
 >shouldn't be highly dynamic at all - they should "never" stop and
 >should attempt to recover if a thread does do so. Typically of course,
 >such systems end up using some higher level abstractions for
 >inter-thread communication anyway, so the chances of "accidentally"
 >sharing stack data are slim. I do think a warning is appropriate -
 >there is an awful lot of code out there that "works" despite
 >these sorts of issues being ignored, I just hate fixing them :-)

How about this as a FAQ entry (I'm not sure where else to put it):

Q. Is it safe for threads to share automatic storage duration (stack) 
objects via pointers or references?

A. Only if you can guarantee lifetime of the stack object will not end 
while other threads might still access the object.  Thus the safest 
practice is to avoid sharing stack objects, particularly when in designs 
where threads are created and destroyed dynamically.  Restrict sharing of 
stack objects to simple designs with very clear and unchanging function and 
thread lifetimes.

Comments?

--Beman