Implement combinator that forbids descheduling

[jasagredo]

Is your feature request related to a problem? Please describe.

Some actions are expected to be performed immediately after others, with prompt execution. I can think of two specific cases:

• When running an async action, the TVar with the result is written, then the thread finishes. If this step is not promptly executed, the thread can remain alive leading to SloppyShutdowns.
• When observing values from an IOSim action, it is often done via a TChan or TQueue to which we push messages when some step completed. If these are delayed, the values sent to the channel can be inconsistent with what we would like to observe from the other side of the channel.

Describe the solution you'd like

I would like to have a combinator that specifies an action cannot be descheduled, i.e. that there can't be a Yield or a Reschedule in between two actions. Something like the following:

foo :: IOSim s a
bar :: IOSim s b

promptly :: IOSim s a -> IOSim s b -> IOSim s (a, b)

baz :: IOSim s (a, b)
baz = do 
  foo `promptly` bar 

or

foo :: IOSim s a
bar :: IOSim s ()

promptly :: IOSim s a -> IOSim s () -> IOSim s a

baz :: IOSim s a
baz = do 
  foo `promptly` bar 

When evaluating foo we could look ahead and if the next action was marked promptly then forbid a reschedule.

Describe alternatives you've considered

Additional context

Could be used in the QSM PR #179. Now I am doing a hack which is checking that before sending the message to the channel that same thread id has done some action that resembles some "work" (see hasDoneWork), which was just an ad-hoc solution.

Are you willing to implement it?

• Are you? 😃 Yes with some mentoring 😄

[bolt12]

From my small understanding of IOSimPOR internals this should be doable without much complexity. IIRC there's a function that deals with the race reversal logic and that would be the place to start looking

[coot]

If these are delayed

Would it help if you don't mark the thread which observes the value as racy? Then IOSimPOR will not take it into account and reorder its steps relative to other threads.

I wonder if you can use traceTVar for your purpose. It has the semantics you're looking for: it is executed always in the same step as the stm transaction.

As for implementation. You'd need to add a constructor to SimA type with the right type, e.g.

promptly :: m a -> m b -> m b

(that's slightly more general what you suggest).
Then we will need Promplty :: SimA s a -> SimA s b -> SimA s b constructor of SimA or something similar (I am using GADT notation).

[jasagredo]

The problem is not the thread that observes the value but the one that emits it. I would like to make sure that the emission is promptly executed.

[coot]

And what about traceTVar or something similar? That's what allows to observe committed values to TVars (we could also add it for other data structures, since all shared variables are now modeled by TVars, it should be doable - we already do that 😁).

[coot]

I think I got what you want to do in the QSM PR, basically:

  cresp <- semantics sut ccmd
           `promptly`
           atomically (writeTQueue tq (ccmd, cresp))

That's why the type signature you want is IOSim s a -> IOSim s () -> IOSim s a. To answer myself: that's not possible with traceTVar.

If we do:

promptly :: IOSim s a -> IOSim s b -> IOSim s (a,b)

Then it could be used to also to readTVar inside the action (an alternative for traceTVar, but only available for IOSim).

It's implicitly included in your request just to add it to IOSim without a type class in io-classes - which I think is fine.

It might be simpler to implement:

promptlySTM :: IOSim s a -> STM s b -> IOSim s (a,b)

You'd want the second argument to be executed atomically. In the case of IOSim s b, this will require heavily modifying the scheduler (which could be error prone concerning POR), while STM is already atomic. This would work for both async and your PR.

[coot]

@jasagredo we came up with an idea to add an operator:

withRaces :: Sim s a -> Sim s a

which enables race discovery for thread that runs the computation (and all thread that are forked from it), but only limited to the Sim s a passed to it.

[coot]

Hmm, I actually need to look at the default IOSimPOR scheduler if it will allow us to solve your issue.

[coot]

I looked at my presentation. Each thread is rescheduled in these conditions (regardless if a thread is racy or not)

• forking a new thread
• thread termination
• setting the masking state to interruptible
• popping masking frame (which resets masking state)
• thread delays
• execution of an STM transaction
• blocking throwTo

It seems the only option is to add promptlySTM.

[bolt12]

Why do you say that? If you don't call exploreRaces IOSimPOR won't find races right?

[coot]

But it will deschedule the current thread and it might pick another one, isn't it?

[coot]

IOSim scheduler runs a thread until it blocks, IOSimPOR uses different scheduler.

[bolt12]

Yes and that's okay, if the thread blocks we can't run it anyway, it would be a problem if this combinator would cause deadlocks.

[coot]

If we have promptly :: IOSim s a -> IOSim s b -> IOSim s (a, b) then the second argument, e.g. IOSim s b, could be non-atomic (e.g. run multiple steps). Which would be surprising from the user perspective. We couldn't guarantee that its all steps are promptly executed.

If we have promptlySTM :: IOSim s a -> STM s b -> IOSim s (a, b) then the stm action is atomic, we only need to make sure the stm action is promptly executed. Btw, promptness has nothing to do with race discovery; we need to make sure that if the next step is executed through it, we don't reschedule the thread when we start to run it. We can leave the racy flag on. Still, if the STM s b action is blocking, then it wouldn't be executed promptly. We could include a warning in the trace for such a case, since this is a user error.