- resent after someone made Spamhaus remove the @talktalk.net e-mail blacklisting entry -
Didier Kryn <k...@in2p3.fr> writes: > Le 26/07/2016 12:59, Rainer Weikusat a écrit : >> Didier Kryn <k...@in2p3.fr> writes: >>> Le 25/07/2016 01:29, Rainer Weikusat a écrit : >>>> Sleeping on a contended mutex is implemented in this way. But that's >>>> supposed to be an exceptional case. >>> This is why, while advertizing itself as a cool "don't care" >>> feature, a mutex is problematic: >> I don't know who's advertising that "don't care" use of shared variables >> would be "cool" and who's being targetted by this advertising (and I >> don't even want to know) but I don't share this opinion. This applies >> equally to single-threaded and multi-threaded applications. A mutex is a >> synchronisation primitive useful for implementing userspace inter-thread >> communication facilities (this is a bit too general). > > This bias of mine comes from the fact that, in high level > languages, mutexes are embedded inside dedicated objects, and the > application can assign values to these objects exactly as it would do > for any other object (without specific care). This could refer to Java 'synchronized things'. But these provide some kind of high-level synchronization object called 'a monitor' and 'mutexes' (mutual exclusion locks) are just a primitive necessary for implementing one. And the "use just like the global variables you'd otherwise use" seems to suggest a programming style you seem to consider more universal than I do. Assuming I filled in the blanks halfway correctly, that's still a certain style of programming which is already not a terribly good idea for a single-threaded application. Using it in a multi-threaded one 'multi-threads' the inherent problems. This would be an example how one can utilize the potential of more 'modern' technical (shared memory multi-processors aka 'multicore CPUs') to achieve the same effect (create a total chaos) much faster :->. [...] >> In case it [hold more than one lock] is, care >> must be taken to ensure that they always try to acquire all members of >> the shared set of mutexes in the same order to avoid deadlocks. >> > All threads aquiring locks in the same order, this is equivalent > to having only one lock, no? A so-called deadlock occurs if one thread of execution holds a lock A and tries to acquire another lock B while some other thread tries to acquire A while holding B. This means thread #1 blocks until thread #2 releases B and thread #2 blocks until thread #1 release A. Since they're now both blocked, none of them will ever release anything. This can be avoided by ensuring that each thread which needs to hold A and B acquired A first and B second. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
