Description [New]

In many projects, it is desirable to be able to utilize the breadth of what is available to RIOT in code triggered by interrupts. However, many of the important system functions (such as mutex) are not available for use inside of ISRs. Consequently, many important drivers such as I2C and SPI are also not available. Currently, the netdev drivers implement a separate thread that the ISR hands events off to, but doing this for everything is potentially infeasible. See discussion below.

Previous text [Outdated]:

Description

On systems that use an interrupt to do a thread context switch mutex_lock(mutex) does not block as expected when inside an ISR and the mutex is already locked.

Steps to reproduce the issue

On a system such as esp8266, issue an i2c_acquire(dev) or similar while inside of an ISR and while the same device is already acquired. I expect that this can be reproduced on other systems that use an interrupt to do a thread context switch.

Expected results

The system yields to another thread until the mutex is unblocked.

Actual results

The thread yield is put off until after the ISR completes, and the ISR's access collides with whatever is already using the bus.

Versions

Board was an esp8266-esp-12x. Initial behavior found by @gschorcht in #10430, but I am following up on what is causing the issue.

References

#10430 Adds support for an I2C-based GPIO expander, and utilizing this device to generate a pin interrupt that alters the state of another expander pin causes some strange behavior. See @gschorcht 's explanation of the behavior here.