ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> boost
boost
Re: [boost] Enhanced call_once()
by Andrew J Bromage other posts by this author
Aug 9 2002 12:33AM messages near this date
Re: [boost] Enhanced call_once() | Re: [boost] Enhanced call_once()
G'day all.

On Thu, Aug 08, 2002 at 09:35:19AM -0500, William E. Kempf wrote:

>  I think I get what you mean, though I think you made some poor choices in
>  comparison here.  "Lightweight" mutexes are an optimization, as are atomic
>  counters.  Your "once" object, as pointed out, won't provide any
>  optimisations.

Several people have claimed this, and I respectfully disagree in
part.  It won't provide any optimisations on many platforms
(especially the ones we wouldn't optimise for), but I believe it
will on others.

>  The abstraction might still be appealing, which I think was
>  your point here, but it still misses the point that it's dynamically
>  initialized, which is not thread safe.

I'm still thinking about this, by the way.  I haven't completely
convinced myself that dynamic initialisation is inherently unsafe.
For example, is it sufficient to issue an explicit fence after the
hypothetical once object is initialised?

>  Whoa.  Careful there.  There's a lot more to once routines then "protecting
>  a read of a single flag which is only going to be mutated once in its
>  lifetime".  In fact, the flag is an implementation detail, *NOT* the
>  resource that's being synchronized.

True.  I was playing fast and loose with terminology here.

>  What's being synchronized is the call to the routine,
>  and the important thing is that any thread that attempts to
>  call this either actually calls the routine if it was the first, or blocks
>  until the routine has been called and returns.

You've mentioned two things that may happen.  In fact there are three,
and the one you left out is precisely the one that the DCL idiom is
meant to optimise, namely, the case that the single routine call has
already completed and therefore does not need to be called again.  In
this case, the caller should not (in theory) need to block.

The problem is the "in theory" part, of course.

Cheers,
Andrew Bromage
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thread:
Andrew J Bromage
Peter Dimov
Andrew J Bromage
William E. Kempf
Andrew J Bromage
William E. Kempf
Alexander Terekhov
Pete Becker
Andrew J Bromage
Peter Dimov
Andrew J Bromage
William E. Kempf
Andrew J Bromage
William E. Kempf
Rene Rivera
William E. Kempf
Andrew J Bromage
Jason Stewart
Andrew J Bromage
Andrew J Bromage
Rob Stewart
William E. Kempf
William E. Kempf
Alexander Terekhov
Peter Dimov
Peter Dimov
Pete Becker
William E. Kempf
William E. Kempf
Pete Becker

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved