posix/sockets: Prevent deadlock with multiple posix TCP sockets

[RainbowSimon]

Contribution description

When 2 posix TCP sockets in different threads are open and the first one is in accept() the mutex of the socket pool was not unlocked until data was received. When another thread calls a function which needs the socket pool mutex there was a deadlock. Unlocking the mutex after all operations on the socket pool are done, in particular BEFORE sock_tcp_accept() solves this.

I verified all function calls between my insertion and the later mutex unlock do not access the socket pool.

Testing procedure

Since this change is small I hope it is sufficient to describe the problem:

In one thread open a posix socket and accept(), this blocks until data is received.
In another thread call any other socket pool dependent posix/socket function, like socket().

Expected:
Second thread can create/... sockets.

Actual:
Deadlock, as the socket pool is still locked.

Issues/PRs references

None, just found this without creating an issue, while porting posix dependent code.

[riot-ci]

Murdock results

✔️ PASSED

0fa8104 posix/sockets: Prevent deadlock with multiple TCP sockets

Success	Failures	Total	Runtime
10516	0	10516	30m:33s

Artifacts

• Documentation preview

[crasbe]

With your proposed solution, wouldn't the mutex be double-freed in line 578 if everything goes successfully?
When two threads are running, this could accidentally free the mutex from another thread if I understand it correctly. Of course the timing has to be just right for that to happen, but it looks like a race condition.