Re: [boost] [Review] Lockfree review: today (July 28th) is the last day [SEC=UNCLASSIFIED]

Subject: Re: [boost] [Review] Lockfree review: today (July 28th) is the last day [SEC=UNCLASSIFIED]
From: Levy, Gabriel (Contractor) (Gabriel.Levy_at_[hidden])
Date: 2011-08-16 04:56:59

UNCLASSIFIED

> > - What is your evaluation of the potential usefulness of the
> > library?*
> >
> > Not developing real time solutions myself, so I can't fully judge. 
> > On
> the
> > other hand, a wait free buffer is quite likely to be a very welcomed 
> > solution for many non real time high performance applications 
> > (starting
> by
> > IPC and boost::interprocess ;).
> 
> i've spent some time to analyse if using it via boost.interprocess 
> will be reasonable/feasible. the answer is: it depends on the CPU and 
> the implementation of atomic<>. if the CPU is supported by 
> boost.atomic, then it is no problem. if the standard library provides 
> atomic<>, it shouldn't be a problem, either.
> however if boost.atomic has to emulate the atomic operations, it will 
> use a pool of spinlocks (the same spinlock pool that is used for the 
> smart_ptr library).
> afaict there spinlocks won't be shared among the different proceses ...

That's really good news, Tim, that principally it would not be a problem as long as the atomic<> can work with boost::interprocess.
That point about atomic<> is quite critical and I would strongly appeal to the author of the "boost::atomic" (Helge Bahmann) to also revisit the atomic library to make, for instance, the type of spinlocks pulled out as a template parameter with maybe defaulting to the ordinary spinlocks. That way if you need to use atomic in boost::interprocess compatible fashion (or anyone else in other applications for that matter) you can plug in a different/custom spinlock. Haven't looked into the atomic's implementation and maybe it's already done that way but if not, Tim, you might bring this need up with Helge. Is that feasible?

It's worth noting that Ion Gaztañaga (the author of boost::interprocess) has submitted a new generic Containers library for review which provides among other kinds also alternative implementations (AFAIK) for STL containers which have been suffering from the issue of not pulling out the pointer type typedefs from the supplied allocators, hence they've assumed that "pointer" means kinda "raw pointer".
So what I'm trying to say here is that there is a good progress made in the land of boost's other parts' compatibility with interprocess library, so it would be real missed opportunity to rush with this lib release and omit the interprocess support. (sorry for pushing the point repeatedly :-\)

I hope it make sense to youse all.

> unfortunately there is no way to catch this at compile-time :/

Not easily, but things like that could be perhaps addressed in later updates.

I'm really looking forward to this lib and the atomic<> - the long missing component in C++ libs. 

Thanks very much
gabe
 
Gabe Levy
Senior Software Engineer, HiQ Systems Pty Ltd

IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email.