examples/cord_ep: Dead lock when (re-)registering in callback function

[MatthiasBraeuer]

Description

I was using the cord_ep example and wanted to automatically (re-)register to an resource directory when the cord_ep_standalone_cb_t is executed with the CORD_EP_DEREGISTERED event passed to it.

When I call the register function in sys/net/application_layer/cord/ep/cord_ep.c though, I produce a dead lock, because the function tries to lock a mutex, which is still locked by the function calling the callback function.

Short: cord_ep_standalone thread => cord_ep_update =>
cord_ep_standalone_signal, => application callback => cord_ep_register.

Possible Solutions:

1. Unlock the mutex before calling cord_ep_standalone_signal (You should do this in all cord_ep functions where cord_ep_standalone_signal is called)
2. Use a recursive mutex, so that the same thread can lock a mutex multiple times and therefore registering in the callback is possible
3. Remove the call to cord_ep_standalone_signal within cord_ep, because cord_ep_standalone#_reg_runner is actually calling the callback (Currently the callback is triggered twice when an update fails, which is not wanted behavior anyway).

Solution 3 is probably the best, because it fixes triggering the callback twice and the dead lock issue as well (Do not forget to remove the timer (xtimer_remove(&_timer);) when the update failed, so that the thread will not try to update as long as the device is not (re-)registered).

For all the other functions in cord_ep.c that call cord_eap_standalone_signal, unlocking the mutex before calling it would be probably the best.

Steps to reproduce the issue

1. In /examples/cord_ep set a callback function (cord_ep_standalone_reg_cb(cord_ep_standalone_cb_t cb)) and register to a resource directory via cord_ep_register(const sock_udp_ep_t *remote, const char *regif) in main
2. In the callback function call cord_ep_register
3. Execute the example => you should end up in a dead lock

Expected results

You can call any function of cord_ep in the cord_ep_standalone_cb_t without producing a dead lock.

Actual results

Calling a any function of cord_ep in the cord_ep_standalone_cb_t causes a dead lock.

Versions

[haukepetersen]

Good catch, I actually forgot to document that you should not call any cord_ep functions from within the callback... Also I was able to reproduce the issue that the CORD_EP_DEREGISTERED event is fired twice on a failed update.

And I agree, that the code easily can be improved to make this possible, so lets do that :-)

see #12996