RE: [boost] RFC: Multithreading design constraints -- SMP vs. uni processor

From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-06-09 07:41:47

I admit, at first, I was a bit repulsed by the idea of having two MT-safe
versions of a library, however I am beginning to embrace the desire to
create the most efficient binary possible.

However, it is impossible to tell reliably at compile time whether the
target platform is SMP or not.  Because of this fact, we should opt for
safety and ease of library use over possible gains in efficiency.

If two versions are chosen, I feel that the default BOOST_MT version should
be safe for SMP, with the uniprocessor version ( BOOST_MT_1P ? ) as a
special optimization that could be activated only by a macro definition.
This way, the library would be safe for anyone to use "right out of the
box", but those who need a tad more speed on a uniprocessor system can RTFM
to learn that they should define a preprocessor macro in their Makefile or
project file.

Mark Borgerding

> -----Original Message-----
> From: Branko Èibej [mailto:branko.cibej_at_[hidden]]
> Sent: Friday, June 09, 2000 8:17 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] RFC: Multithreading design constraints
> 
> 
> Peter Dimov wrote:
> > 
> > > I think we need to be prepared to treat SMP 
> synchronization with a separate
> > > value of BOOST_MT. Non-SMP synchronization could in 
> theory be much more
> > > efficient.
> > 
> > But SMP vs non-SMP is not a compile time decision, is it?
> 
> It _could_ be. Some processors that are widely used in SMP 
> environments
> are also widely used in embedded environments (e.g., PPC), 
> for which you'd
> definitely want to choose the more efficient implementation 
> at compile time.
>