Re: recursiveness of Glib::Mutex::Lock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 






On Sat, Jan 12, 2013 at 12:13 PM, sam tygier <samtygier@xxxxxxxxxxx> wrote:
Hi,

I am hitting a bug in rawtherapee ( http://code.google.com/p/rawtherapee/issues/detail?id=1675 ) which appears to stem from a difference between the behaviour of Glib::Mutex::Lock() on linux and windows. The multithreading was originally written on windows, when it was tested on linux there were dead locks, to several of the Lock() calls were commented out. Now I am hitting cases where the threads interacted badly, and so want to get the locks right on linux.

recursive locks are considered evil by the people who invented them and still know more about threading semantics than almost anyone else around.

use google to look it up. there is a "famous" article from the person who first implemented recursive mutexes on one of the early unix systems, explaining how he did it to prove *how bad they were* and his disappointment that too many people didn't get the joke.

the same article explains *why* they are so problematic (in a nutshell: they are band-aids over program design flaws).

_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list

[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux