Re: recursiveness of Glib::Mutex::Lock

On Sat, Jan 12, 2013 at 12:13 PM, sam tygier <samtygier yahoo co uk> wrote:

I am hitting a bug in rawtherapee ( ) 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).

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