Re: [boost] [review] Fast track review of Boost.Utility/Singleton begins today

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2008-01-17 11:47:09

Tobias Schwinger <tschwinger <at> isonews2.com> writes:

> 
> Gennadiy Rozental wrote:
> > "Tobias Schwinger" <tschwinger <at> isonews2.com> wrote in message 
> > news:fmkefr$cf3$1 <at> ger.gmane.org...
> >>> For instance, the design
> >>> could be made more flexible by allowing thread-safety to be specified as 
> >>> a
> >>> policy (with appropriate default) or by delegating the responsibility to 
> >>> the
> >>> wrapped type.
> >> OK, FWIW policies complicate things. And what's their benefit here?
> > 
> > I disagree. In general policies promote modularization. In this concrete 
> > case policy based solution would allow more flexibility in how "thread-
safe" 
> > I want to be.
> 
> They often also promote over-complication:
> 
> Thread-safety that is more complex than applying a simple mutex is very 
> case-dependent and should be implemented manually.
> 
> > 
> >>> If BOOST_HAS_THREADS is defined, it looks as though I have no
> >>> choice but to use mutexed instantiation and/or access.  If I'm not
> >>> interested in synchronised access, then the lease interface is useless.
> >> Wrong:
> >>
> >> The lease interface is useful to improves performance. The test whether
> >> the Singleton has been initialized (which requires synchronization) can
> >> be performed only once.
> > 
> > The lease interface only improves preformance in your design. With Meyer's 
> > singleton instance() is as efficient. With any other solution that returns 
> > T&, I just need to store local referene to the target type.
> 
> Storing the instance is out of the question with automatic locking.

No. This is not true. If I use singleton<sincronized<T> >, instance method 
returns syncronized<T>& and access is syncronized. But promoting automated 
locking of all the class methods is bad idea as well IMO. This is strait road 
to deadlocks. I'd prefer syncronization to be implemented as part of class T, 
which knows specifically what to syncronize. 

If I want to have some kind of automation, I may go with something like this, 
for example:

A : singleton<syncronize_IO<A> >.

singleton should suppport this usage. 

Gennadiy