RE: [boost] Re: On boost.threads

From: johan.nilsson_at_[hidden]
Date: 2001-09-11 02:22:46

So,

please don't flame me if I'm missing out something already covered in this
debate. I've been reading quite a few of the posts involved (which are
numerous).

On the concept of mutex/cs/optex etc: why not simply parameterize on the
synchronization wrapper type that's used for locks, provide a reasonable
default ('mutex'?) but thus also allow users to define and provide their own
type for usage (read 'critical section')? It would then be possible to make
typedefs in your project/app specific include files, like:

---
typedef boost::thread<myown::critical_section> thread_t;
---
and use this in your application.
// Johan
> -----Original Message-----
> From: williamkempf_at_[hidden] [mailto:williamkempf_at_[hidden]]
> Sent: den 11 september 2001 04:33
> To: boost_at_[hidden]
> Subject: [boost] Re: On boost.threads
> 
> 
> --- In boost_at_y..., "Ed Brey" <edbrey_at_y...> wrote:
> > From: <williamkempf_at_h...>
> > 
> > > This was the article that someone pointed me to.  The conclusion 
> was
> > > that CS are only faster if:
> > >
> > > * There are less than 8 threads total in the process.
> > > * You weren't running in the background.
> > > * You weren't on an dual processor machine.
> > >
> > > To me this means that simple testing yields good CS performance
> > > results, but any real world program is better off with a full 
> blown
> > > mutex.
> > 
> > Ouch.  The project I'm working on has a Windows GUI application 
> running
> > in a GUI thread and a network communication subsystem working in a
> > separate thread.  The reason for the thread separation is not for
> > multi-processor parallelism, but rather so that the GUI folks can 
> block
> > and take all day on some operations without having to worry about 
> the
> > soft real-time nature of the network.  This application will almost
> > never be run on a dual processor computer (at least not for years to
> > come), will be run in the foreground, and will have just a handful 
> of
> > threads.  Yet performance is important since customers' computers 
> are
> > often old and slow and there is a lot of data to handle.
> > 
> > I have a hard time believing that such a situation as mine is all 
> that
> > rare.
> 
> Not rare, but not the norm for MT applications either.  Don't take 
> this wrong from me, I am not suggesting we totally for go critical 
> sections (or more likely an optex) in the implementation.  My 
> reasoning is simply that there's some evidence that a CS actually 
> performs worse in some situations (which I would consider to be the 
> norm) so given the issues I've laid out with the implementation I 
> chose to initially go with just a mutex.  I expect that we'll do some 
> research and some experimentation on this issue and may very well 
> change the implementation later.  However, it's just an 
> implementation detail and *IF* someone has immediate need for a CS 
> implementation it doesn't take much to roll your own.
> 
> > A macro to choose the implementation method would do just the trick.
> > This also could would open the door to allowing <windows.h> into the
> > header without any concern of harm, since the default could be to 
> use
> > the mutex.
> 
> I'm not totally adverse to this approach, though I think it adds 
> unnecessary complexity and makes it harder to switch completely to a 
> CS/optex implementation in the future.
> 
> Bill Kempf
> 
> 
> Info: http://www.boost.org  Unsubscribe: 
<mailto:boost-unsubscribe_at_[hidden]> 
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/