Re: [boost] [lockfree] Review

Subject: Re: [boost] [lockfree] Review
From: Grund, Holger (Holger.Grund_at_[hidden])
Date: 2011-07-30 14:32:04

Thanks Tim,

I'll see if I can address individual points later. So just the important stuff :-)

> > of shortcomings, but one is particularly bad: atomic<tagged_ptr> is
> not
> > actually lock-free for Visual C++. The DCAS implementation should be
> > straightforward, but seems to be absent . in case you wonder I did an
> > initial implementation of <(cstd)atomic> and added all required
> intrinsics
> > for a simple implementation to the compiler. These made it all into
> > VC++2010 RTM (IIRC, there was only one 64-bit, most where 8 & 16-bit
> > variants)
> 
> i don't have access to any msvc compiler, do you think you could
> contribute the
> msvc-specific code for boost.atomic?
> besides, i have a version that only requires 32bit cas.
> 
If you find a Windows OS, there's always the VC++ Express download.

Anyhow, I think this should be straightforward. I didn't look at it in detail, but it looked like you only need a specialization with size 8 types that does a _InterlockedCompareExchange64 for most everything. Efficient loads & stores are a bit tricky in that SSE2 is not a requirement for 32-bit Windows. Without it, I think we need to resort FILD/FISTP, which is a pain.

I see if I can code this up. No promises, though.

> > There are a few points that make me a bit nervous. Specifically, the
> > alignment story is a bit weak. It seems there is only one use of
> > BOOST_LOCKFREE_CACHELINE_ALIGNMENT and that's for fifo<>::node. Older
> > compilers (GCCs and VC at least) don't dynamically align the stack
> with
> > __declspec(align)/__attribute__((aligned). Other classes do not use
> > alignment at all.
> 
> i don't know of any standard-compliant c++ way to enforce a specific
> alignment.
> it doesn't affect the correct, but is merely a hint for the compiler
>
Well, I hope that at least atomic<> gets it right. Nonaligned accesses are not guaranteed to be atomic. 
In this case I guess, the atomic<> implementation ends up using a uint64_t. In VC++ __alignof == 8, but that doesn't mean that autos of type uint64_t are necessarily aligned. In our case I would assume that you get memory from the OS to be at least 16 or 8 byte aligned and the alignment of class types should be fine.

We should probably have a closer look, though.

E.g.: consider this on x86 with an older GCC
void foo()
{
   atomic<tagged_node_ptr<X> > x;
}

Is x aligned, here? I don't recall the ABI, but I believe it doesn't guarantee anything beyond 4-byte alignment for ESP on entry. So to align x properly in the stack frame, the stack must be dynamically aligned (or some interprocedural optimization may help) -- but I don't think older GCCs do that.

Same problem on Windows with VC++ for x86. However, dynamic stack alignment is only done under certain circumstance (I think, only when the codegen sees loads/stores of double or __declspec(align)ed objects from/to mem). It doesn't for uint64_t, however.

Thanks!
-hg
 

--------------------------------------------------------------------------
NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.