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

[Markus Mottl <markus.mottl@gmail.com>]

That's a good point.  I had never seen a problem with this, but wasn't
sure whether this is just due to my particular use cases in the past
(may have involved atomic values only) so I've verified this in the
source now to be sure.  The "caml_ref_table", which contains all
fields on the major heap that refer to the minor heap, will be
reallocated if it runs out of space, but I don't see any place where
this would actually run the GC.  The same seems to be true of the
"gray_vals" table that may also get involved.  I guess such
reallocations are exceedingly rare in practice, because the GC will
usually run before the tables get full and clear them out.

I'm sure the OCaml team will let us know if I missed anything, but I
think assignments are safe in all circumstances (including your
example), no matter what the source or destination values are.

On Thu, Aug 15, 2013 at 9:28 PM, John F Carr <jfc@mit.edu> wrote:
> 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
>>
>
>
>
> --
> 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



-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com