[Caml-list] Where's my non-classical shared memory concurrency technology?
On Sun, May 18, 2008 at 12:03 AM, Jon Harrop [EMAIL PROTECTED] wrote: Avoiding threads does not improve the safety of the language, it simply degrades the capabilities of the language. Avoiding threads is like avoiding malloc() in a C program and doing only static and stack allocation: it is cumbersome and impractical, but avoids a whole class of allocation bugs. Similarly, avoiding threads removes concurrency bugs - while reducing the concurrency capabilities. So it's not really improvement of safety, but rather avoidance of unsafety - a purely semantic issue. I think we are still lacking programming language technology to integrate safe and easy-to-use shared memory concurrency in ML-like languages. Does anyone know of anything in this area aside from transactional memory? -- Berke ___ 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
[Caml-list] ANNOUNCE: bitmatch 1.0
I'm pleased to announce the first stable release of bitmatch, version 1.0. We have a NEW home page: http://code.google.com/p/bitmatch/ Bitmatch adds Erlang-style bitstring matching and construction syntax to OCaml. It makes parsing binary files, formats and protocols exceptionally simple. It has numerous features including 1-64 bit integers, strings, efficient subsets of bitstrings, big- and little- endianness, signed and unsigned types, variable-width fields, and fields with arbitrary bit-level alignment. You might also want to check out our tool virt-df which uses bitmatch to parse a wide variety of disk formats: http://et.redhat.com/~rjones/virt-df/ The source code for the diskimage library is a good place to see bitmatch in real world usage: http://hg.et.redhat.com/virt/applications/virt-df--devel?cmd=manifest;manifest=64ac2a858070b95bc02445b9bb966786e84bebe7;path=/lib/ Bitmatch is available under the GNU LGPL version 2 or later with the usual OCaml linking exception. Rich. -- Richard Jones Red Hat ___ 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
[Caml-list] Re: Where's my non-classical shared memory concurrency technology?
On Sunday 18 May 2008 09:39:15 Berke Durak wrote: On Sun, May 18, 2008 at 12:03 AM, Jon Harrop [EMAIL PROTECTED] wrote: Avoiding threads does not improve the safety of the language, it simply degrades the capabilities of the language. Avoiding threads is like avoiding malloc() in a C program and doing only static and stack allocation: it is cumbersome and impractical, but avoids a whole class of allocation bugs. Similarly, avoiding threads removes concurrency bugs... Are you sure? Can you not still have two agents mutually waiting on each other for a message (a deadlock) or messages not being ordered before consumption (a race condition)? I don't believe you have removed any concurrency bugs. I think you just pushed them around a bit. I think we are still lacking programming language technology to integrate safe and easy-to-use shared memory concurrency in ML-like languages. Does anyone know of anything in this area aside from transactional memory? Data parallelism in Microsoft's Task Parallel Library. I have no use for STM myself. -- 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
