RTS's (old?) invariant regarding OS blocking
Dan Aloni
dan at kernelim.com
Thu Mar 3 11:00:28 UTC 2016
On Thu, Mar 03, 2016 at 09:52:07AM +0000, Sergei Trofimovich wrote:
> On Wed, 2 Mar 2016 16:38:56 +0200
> Dan Aloni <dan at kernelim.com> wrote:
>
> > Hi,
> >
> > While trying to gain insights into the RTS, I've noticed the following in
> > the Wiki page [1] on the topic of the scheduler:
> >
> > Invariant: a task that holds a capability is not blocked in the operating system.
> >
> > This makes some parts of the system simpler - for example, we can use spin locks that spin indefinitely, because we can ensure that the spin lock is only held by a currently executing CPU, and will therefore be released in a finite (and short) amount of time.
> >
> > Does it still apply to modern day GHC, or was it addressed by [2]?
>
> It still does apply. Foreign calls are by default 'safe' and executed
> after Capability is released to a separate OS thread.
> Capability release is needed as foreign calls can reenter haskell RTS.
Thanks for the elborate example - however my concerns extend beyond
the safe vs. unsafe FFI. I was concerned about the spin lock, and about
hard host kernel scheduling assumptions thereof.
I looked into the GHC code now, and the locks in Capability.c on Linux
seem to translate to pthread_mutex_lock(), which is a futex. This is
a relief. Does the wiki need updating?
--
Dan Aloni
More information about the ghc-devs
mailing list