[Development] Mutex future directions

[Thiago Macieira]

On sábado, 19 de maio de 2012 10.26.03, Thiago Macieira wrote:
> > But fast uncontended case is critical because it allows the use of mutex
> > in
> > part that might or not be used with threads. Example: QObject. We need to
> > put mutexes while emiting a signal because maybe it is used in multiple
> > thread. But we don't want to pay too much when used in a single thread
> > (the
> > common case)
> 
> That's a very good example of where we want QMutex to be transactional: we 
> need the mutex because we need to be sure that no other thread is modifying 
> the connection list while the signal activation is reading the lists.
> However, we know that it's an extremely rare case for that to happen. If we
> have TSX in the signal emission path, then two threads could read from the
> signal list simultaneously.

As Lars's email pointed out, this is a non-example since it is located inside 
QtCore. We can use the inline mutex as much as we want here and change it in 
any way we want in future versions.

For that matter, the signal emission need not use even QBasicMutex. If we want 
a RWlock semantic, we can change to a different structure at any time, 
including a TSX-optimised one.

> In other words, with TSX, QMutes becomes a QReadWriteLock with no extra
> data  cost.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120519/c404f5ba/attachment.sig>