Re: [Caml-list] Threads and "transaction isolation" in OCaml

[John F Carr <jfc@MIT.EDU>]

Do you mean allocation or garbage collection?

Generational garbage collectors can collect without allocation when you 
assign a
young object to a field of an older object.  There is (or may be) a list of
intergenerational (older to younger) references.  When that list exceeds a
threshold, the GC may do a minor collection.

I have not checked what the current implementation of OCaml does in this case.

let x = ref (ref 0) in
let y = ref 1 in (* allocation triggers GC; x is old and y is young *)
... work here ...
x := y (* may cause GC *)


> Hi,
>
> I just wondered how much we can rely on current OCaml-semantics where
> context-switches are impossible as long as there are no allocations.
>
> E.g. pattern-matches, array and record field assignments, etc., can be
> safely chained together in one "transaction" without having to fear
> that another thread will interrupt them.  This is extremely useful for
> optimizing certain applications where lock acquisitions might just be
> too expensive.
>
> There already are some corner cases where things may be
> platform-dependent, e.g. calling functions tail-recursively that take
> more arguments than there are available CPU-registers.  In that case
> the compiler may pass arguments by allocating blocks on the heap.  But
> I think people that care about such obviously brittle semantics know
> where to be careful.
>
> Anyway, is it considered reasonably future-safe to write code of that
> sort?  I'd rather not have new compiler optimizations, etc., interfere
> with these assumptions in the near future.
>
> Regards,
> Markus
>
> --
> Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>