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.