RE: [boost] Re: boost.threads

From: Darryl Green (green_at_[hidden])
Date: 2001-08-08 21:06:00

> -----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 :-)

Darryl.