Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Acquisition of runtime lock #4787

Closed
vicuna opened this issue May 7, 2009 · 2 comments
Closed

Acquisition of runtime lock #4787

vicuna opened this issue May 7, 2009 · 2 comments

Comments

@vicuna
Copy link

vicuna commented May 7, 2009

Original bug ID: 4787
Reporter: @mmottl
Status: closed (set by @mshinwell on 2016-12-07T13:27:32Z)
Resolution: won't fix
Priority: normal
Severity: feature
Version: 3.11.0
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @ygrek @glondu @Chris00 @mmottl

Bug description

I 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!

@vicuna
Copy link
Author

vicuna commented May 7, 2009

Comment author: @mmottl

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.

@vicuna
Copy link
Author

vicuna commented Dec 7, 2016

Comment author: @mshinwell

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant