Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004787OCamlOCaml generalpublic2009-05-07 02:542009-05-15 17:01
Reportermottl 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusacknowledgedResolutionopen 
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
(0004952)
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.

- 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


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker