Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004787OCaml~DO NOT USE (was: OCaml general)public2009-05-07 02:542016-12-07 14:27
Assigned To 
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version3.11.0 
Target VersionFixed in Version 
Summary0004787: Acquisition of runtime lock
DescriptionI have run into a problem that seems extremely hard to fix without support in the runtime, but adding this feature to the OCaml runtime is probably quite easy.

A library I have created bindings for supports callbacks from C, which I would like to pass on to OCaml. The thread executing this callback comes from OCaml, but unfortunately I cannot tell beforehand whether it still holds the OCaml-lock at the time of the callback, because there is a large number of entry points, only some release it, and the thread does not hold information as to from which entry point it was coming from.

caml_leave_blocking_section cannot be called when the runtime lock is still being held (-> deadlock) and not calling it if it isn't (-> race) is also not an option so I am stuck. There is currently no exported functionality in the runtime to discover whether the executing thread holds the runtime lock.

Would it be possible to either support recursive acquisitions of the runtime lock or provide for a way to determine whether the running thread holds it? Thanks!
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
mottl (reporter)
2009-05-07 19:02

It seems the easiest and most efficient way to support the requested feature could be the following, and it would even add a safety measure for free:

Export an alternative to the "caml_leave_blocking_section" function, which does the same thing, but returns whether the runtime was already being held by this thread. This function would behave mostly like the ordinary one, but does following:

  1) lock caml_runtime_mutex
  2) use pthread_getspecific right away to get pointer to thread descriptor.
  3) compare this pointer with curr_thread. If different, do the usual thing and return that the runtime needed to be acquired. Otherwise, if the pointers are the same, unlock the mutex, and return instantly with the result that the runtime was already being held by this thread.

The ordinary function could be implemented in terms of the new one. Furthermore, this would then also allow cheap checking of an important invariant: if the ordinary function for leaving blocking sections gets the result that the runtime was already being held by this thread, it could print a deadlock error to stderr before calling "abort" (to get a core dump), which is certainly more useful than just silently hanging forever.

The alternative function would certainly allow me to solve my problem.
shinwell (developer)
2016-12-07 14:27

I think this is unlikely to be implemented, especially with ongoing work on Multicore OCaml. The situation described seems quite niche and I would have thought could be addressed by other means (e.g. a thread-safe queue filled by the C callbacks and read from the OCaml side).

- Issue History
Date Modified Username Field Change
2009-05-07 02:54 mottl New Issue
2009-05-07 19:02 mottl Note Added: 0004952
2009-05-15 17:01 doligez Status new => acknowledged
2016-12-07 14:27 shinwell Note Added: 0016707
2016-12-07 14:27 shinwell Status acknowledged => closed
2016-12-07 14:27 shinwell Resolution open => won't fix
2017-02-23 16:36 doligez Category OCaml general => -OCaml general
2017-03-03 17:55 doligez Category -OCaml general => -(deprecated) general
2017-03-03 18:01 doligez Category -(deprecated) general => ~deprecated (was: OCaml general)
2017-03-06 17:04 doligez Category ~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker