28.08.2012 12:01 пользователь "Thiago Macieira" <thi...@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.