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

[Vadim Zhukov]

28.08.2012 12:01 пользователь "Thiago Macieira" <thiago at kde.org> написал:
> 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
holds
> > > > *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
when
> > > I had tried that initially).
> >
> > Actually I take that back. I was using QAtomicInt, which had that
problem.
> > 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
else.
> 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
ones.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120828/009e5db0/attachment.htm>