[Development] Mutex future directions

[Charley Bay]

<snip, QMutex future-direction-discussion>

I've followed this very technical discussion from the beginning--
impressive array of topics.  Thanks to all digging into this, and great
thanks to Thiago for opening the issue.

I have a question on the point of "recursive-locks":

I understand "recursive-locks" (e.g., "recursive-lock-count") were not part
of the original QMutex, and were added later.  I understand it's merely a
count-lock-wrapper around the *real* lock.

Further, I understand that "recursive-locks" can help
"get-one-out-of-a-corner-in-which-they-find-themselves", where the lock was
already taken by the current thread and we don't want to deadlock when
accidentally attempting the lock again.  This problem tends to occur in
designs where the lock is implied for (small) transactional operations,
*and* for (large) transactional operations that tend to trigger implicit
execution of those (small) transactional operations *within* the large
transactional operation.

I agree with Oliver:

 *) I think recursive mutex don't deserve improvements on the detriment of
>    normal ones


>From a practical standpoint, I understand why recursive mutexes exist (see
description above).  However, from a *logical/cleanliness* standpoint,
every time I've used them, I've later re-factored to where I do *not* do
mutex-recursion.  (Currently I use no recursive mutexes.)

Do people really use them intentionally (do designs legitimately require
them), or are they as I suspect, a way to "get-yourself-out-of-trouble"
when your design failed to account for proper transactional granularity?

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120519/1d254ab8/attachment.html>