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