> On Sun, Feb 21, 2010 at 16:52, Adriaan de Groot
> <groot at kde.org> wrote:
>
> > A solution that was applied earlier in unlock() was
> the following:
> >
> > val &= ~1;
> > mtx=(QMutex*)val;
> > mtx->unlock();
>
> I believe this is the correct solution, and that the
> QMutexLocker::unlock() code is wrong. If you look
> further down inside
> the QMutexLocker class:
>
> inline QMutex *mutex() const
> {
> return reinterpret_cast<QMutex *>(val &
> ~quintptr(1u));
> }
>
> which shows that val must be explicitly
> reinterpret_cast to the
> appropriate QMutex* type before it (or mtx assigned
> to it) can be
> used. The same should happen inside mtx->unlock():
>
> My reading of the -xalias_level=compatible tells me
> that val should
> not alias mtx, because they are not compatible types,
> and mtx is not a
> POD.
some comments from the Qt people:
[23:56] <hajma> thiago_home: I think it might have been related to the use of
-xalias_level CXX flag
[23:56] <thiago_home> yes, compiler bug
[23:56] <thiago_home> note how all 'this' pointers end in 9 or 1
[23:56] <thiago_home> that's because QMutexLocker uses the lowest bit of the
pointer to indicate whether it's locked or not
[23:57] <thiago_home> but it turns them on and off properly. The compiler
optimised out the check.
[23:57] <thiago_home> val &= ~quintptr(1u);
[23:57] <thiago_home> mtx->unlock();
[23:57] <thiago_home> see? It's impossible to call mtx->unlock with a pointer
that ends in 9 or 1
[23:58] <thiago_home> (val and mtx are in a union)
--
This message posted from opensolaris.org
