[Interest] QMap and thread-safe.

Thiago Macieira thiago.macieira at intel.com
Fri Jul 26 09:00:30 CEST 2013


On sexta-feira, 26 de julho de 2013 10:27:28, Mandeep Sandhu wrote:
> > Doing both at the same time is not atomic anywhere unless you use
> > specialised
> > fetch-and-add instructions, which the compiler never generates for you.
> 
> By both here, you mean fetch AND add, right? 

Right

> And in x86 such a operation
> (add) on a machine word is atomic w/o using special instructions?

ADD is atomic, but usually an atomic increment is done with LOCK ADD, to 
ensure that no other processor is trying to access the same memory location. 
The compiler will never generate a LOCK.

In other words, ADD is atomic for single-CPU operations. As soon as there's 
more than one CPU, it isn't enough.

> Eg if I had code like this running on a x86 machine:
> 
> short foo;
> foo++;
> 
> Will the increment be atomic or do I have to explicitly make it so by doing
> something extra?

It will be atomic for something running in the same thread, such as a signal 
handler. It will probably be atomic for multi-CPU too. But you shouldn't do 
it.

> >     return foo++; // not atomic anywhere
> 
> Why? Because of the way foo is being received in this function, i.e by
> reference (so any operation on foo has and added level of indirection)?

Because it's fetch-and-add. Two operations. There's no guarantee of atomicity.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130726/5cdf16e2/attachment.sig>


More information about the Interest mailing list