only check timeouts when a thread yields

[RalfJung]

Currently, we check for expired timeouts after each step of execution. That seems excessive. This changes the scheduler to only check for timeouts when the active thread cannot continue running any more.

@vakaras does this sound right? pthread_cond_timedwait anyway already yields, of course, since it blocks on getting the signal (or the timeout).

[vakaras]

@vakaras does this sound right? pthread_cond_timedwait anyway already yields, of course, since it blocks on getting the signal (or the timeout).

Yes, this sounds correct. However, I noticed that there seems to be no test for this. I would suggest adding it to this file:

miri/tests/run-pass/concurrency/libc_pthread_cond.rs

Line 35 in b3f81fc

libc::pthread_cond_timedwait(&mut cond as *mut _, &mut mutex as *mut _, &timeout),

[RalfJung]

I added a test but it doesn't seem terribly meaningful -- in particular to really check the condition in the spec that is relevant here, we'd need some other thread to be already ready to give a signal so that there is a race between that signal and the timeout. I am not sure how to construct such a situation.

[vakaras]

I think you cannot make a useful test without taking into account the scheduler. However, I think you could exploit the knowledge that the current scheduler never preempts the thread:

1. Prepare the conditional variable.
2. Spin the second thread, get it ready, and yield.
3. On the first thread, call pthread_cond_timedwait.
4. Signal on the second thread.
5. Check that the first thread got ETIMEDOUT.

[RalfJung]

Hm... I think I'll leave adding such a test to future work.^^ If you want to give it a try, feel free to. :)

@bors r+

[bors]

📌 Commit 0674d43 has been approved by RalfJung

[bors]

⌛ Testing commit 0674d43 with merge e6ffc68...

[bors]

☀️ Test successful - checks-actions
Approved by: RalfJung
Pushing e6ffc68 to master...