[Insight-developers] thread safety question
Will Schroeder
will.schroeder@kitware.com
Mon, 19 Feb 2001 07:46:53 -0500
Making each and every method in a class is a monumental task.
It is far easier, and probably just as useful, to make the usage
of each instance of a class thread-safe (e.g., an instance of a class
can be used in multiple pipelines in a thread-safe manner). To make
each method thread-safe, you either a) have to mutex-lock everything
(which is slow), or dynamically allocate temporary storage in a class
on a per-thread basis, which is a huge mess.
Will
At 09:45 AM 2/16/2001 -0500, Paul Hughett wrote:
>Will Schroeder:
>
> > Also, since we are trying to build a toolkit that allows users to
> > assemble pieces arbitrarily, we have to be careful how these
> > auxiliary functions to interact with the rest of the system. If they
> > assume too much about the invoking class, then it can make it
> > too hard to use the functions.
>
>I would recommend the policy that methods be thread-safe unless there's
>some compelling reason not to be; and that any unsafe methods be clearly
>marked as such in their Doxygen descriptions.
>
>
> > Note: you could always set up the auxiliary class/functions to
> > accept a "structure" as part of the invocation/instantiation. This
> > structure would serve as the scratch space, and could be allocated
> > just once per thread.
>
>My understanding of C is that automatic variables are essentially
>free, because you can allocate any number of them at once simply by
>incrementing the stack pointer. (Initialization costs extra, but
>would need to be done in either case.) Is this also the case for C++?
>
>Paul Hughett