Re: [Caml-list] Re: Where's my non-classical shared memory concurrency technology?
Jon Harrop wrote: Similarly, avoiding threads removes concurrency bugs... I don't believe you have removed any concurrency bugs. I think you just pushed them around a bit. I couldn't agree more. If you 'avoid' concurrency by writing your own 'sequential' event handling code, you have not removed the concurrency, you just face it in a slightly different form, and you have to program the event handling code yourself, rather than relying on a tried and tested library, i.e. you have an additional source of bugs, without removing the problems that are inherent in concurrency (e.g. deadlocks, livelocks, fairness ...). There are reasons why writing your own concurrency mechanisms might be the way to go, but it's a highly non-trivial endeavor. Concurrency is hard, and no matter how one presents the concurrency (message passing, shared memory, event handling etc), the fundamental problems will always be there. Data parallelism in Microsoft's Task Parallel Library. I have no use for STM myself. Do you have industrial experience with STM? I wonder how it performs in industrial settings. Reading STM papers by their inventors makes them sound like the best thing since sliced bread, but I have a (probably irrational) feeling that it's difficult to beat fine grained locking if one can handle the programming difficulties their use imposes. Martin Berger ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: Where's my non-classical shared memory concurrency technology?
On Monday 19 May 2008 15:09:04 Gerd Stolpmann wrote: On the contrary: Shared memory parallelization has the fundamental disadvantage that you cannot reason about it, I have been reasoning about shared memory parallel programs for many years. and so the only way of checking the quality of the code is testing. I often assess the correctness of my parallel codes just by reading them. Event handing concurrency, while not giving you parallelization, is basically sequential programming, and it is possible to reason about such programs. Programs are parallelized in the interests of efficiency. Event handling concurrency is orders of magnitude less efficient in the context of CPU-intensive tasks that are not embarassingly parallel so it is not an alternative. With reasoning I don't necessarily mean formal techniques. The more frequent case is that the programmer thinks about the program guided by the laws of logic. Then it is a subjective belief. The impossibility to do this with truly parallelized code is an important source of bugs, so I would say this code inherently more buggy. Your remit is concurrency and not parallelism. i.e. you have an additional source of bugs, without removing the problems that are inherent in concurrency (e.g. deadlocks, livelocks, fairness ...). This is simply nonsense. Different concurrency techniques have different problems. For example, in event handling-based concurrency you do not need locks, hence you cannot run into deadlocks. Two agents cannot proceed because they are waiting on events from each other = they are deadlocked even though there are no mutexes. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: Where's my non-classical shared memory concurrency technology?
On Mon, May 19, 2008 at 11:47 PM, Jon Harrop [EMAIL PROTECTED] wrote: There are two problems with what you wrote in this context: 1. You are replying to a thread about shared-memory parallelism with a discussion of sequential concurrency, which is completely different. 2. You keep saying avoiding threads but what you mean is avoiding parallelism. No, because Ocaml threads today avoid parallelism, but you can still get inconsistency bugs. You'd only get them faster with parallel execution :) In essence, your solution to bugs that arise due to parallelism is to avoid parallelism. While true, that is not going to help anyone exploit multicores. We're going in circles again. I was just arguing, again, that Thread.create + Mutex.lock = more bugs than event-driven execution. Now, yes, that doesn't heat all your cores, so that's why I changed the subject to where is my shared-memory concurrency technology? - not a rhetorical question, but a real one. So, my question is : Given that shared, mutable global state accessed with multiple threads is a recipe for bugs that no amount of data hiding can solve (because -locking-sections-don't-compose-), did anyone invent and implement a usable type or other system for making concurrency and parallelism safe? If the answer is STM, please show me some non-trivial application that uses it, preferably in an impure language. -- Berke Durak ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: Where's my non-classical shared memory concurrency technology?
If the answer is STM, please show me some non-trivial application that uses it, preferably in an impure language. yes, that would be interesting to see. presumably the example would have to come from Haskell, Clojure, or classically some SQL database? i am under the impression that STM is harder to optimize since generally you don't know what the transactions collided on. whereas with a hot lock you can see precisely what code uses that lock and what it locks. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
