Review Request: Add spinlocks lock type, based on GCC intrisincs

Vadim Zhukov persgray at
Tue Aug 28 09:28:24 BST 2012

28.08.2012 12:01 пользователь "Thiago Macieira" <thiago at> написал:
> On segunda-feira, 27 de agosto de 2012 20.29.52, Michael Pyne wrote:
> > On Monday, August 27, 2012 20:18:34 Michael Pyne wrote:
> > > On Tuesday, August 28, 2012 00:41:16 Thiago Macieira wrote:
> > > > QBasicAtomicInt are permitted in unions. Besides, why do you want
it in
> > > > a
> > > > union in the first place? You should not access the data that it
> > > > *except* via the QBasicAtomicInt functions.
> > >
> > > That would be the idea, yes (to use the public QBAI functions).
> > >
> > > The problem with having it in a union was that it's a non-POD type
> > > according to C++ 03 rules (or at least, that seemed to be the issue
> > > I had tried that initially).
> >
> > Actually I take that back. I was using QAtomicInt, which had that
> > QBasicAtomicInt works just fine in the union... yay!
> That's the whole point of QBasicAtomicInt: it's POD.
> Anyway, you haven't explained why you need it in a union with something
> Are you accessing the data outside of QBasicAtomicInt? If so, that's
wrong. if
> you're not, you probably don't need the union.

See the definition of SharedLock structure in kshareddatacache_p.h.
Actually, other union members will not be accessed simultaneously with
spinlock, but compiler doesn't know about that.

Other way would be to get rid of using shared memory for locks at all, but
then there'll be no way for real timeouts, see file-based locking patch
nearby. (sorry for lack of links, I'm from mobile)

Personally I'd prefer not to introduce compiler-related hacks. And there is
no need to worry about code effectiveness: actual access to data in cache
is much, much longer than time spent on acquiring locks, even lockf()-based
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the kde-core-devel mailing list