I have an API (written in C) that permits any number of incoming (concurrent) connections. Each connection is handled by an independet pthread created whenever a client connects to the API.
Each of these connections can (but do not have to) change properties of the server such that requests should not be processed at the same time.
My code basically follows this structure:
pthread_mutex_t lock;
void request_handler(char * request)
{
pthread_mutex_lock(&lock);
process_request(request);
pthread_mutex_unlock(&lock);
}
Assume now one request is being processed that takes a long time (e.g. ten seconds). In this time, five other requests come in, so five additional pthreads will reach at the pthread_mutex_lock function.
- Do they just wait there and continue as intended (one after another is served)?
The reason why I'm asking this is that this is what I'd expect but I haven't found an example with more than one concurrent thread in the official documentation.
- Is there a guarantee that the requests will be processed in the same order in which have been received or will any single one of the five waiting threads be allowed to start after the long request finished?
Strict in-order execution is not needed by my code, but I'd like to know beforehand what to expect in order to design my code properly.
I also read about recursive mutex, but I'd like to avoid them due to a number of reasons. Furthermore, my code will not try to lock multiple times from one single pthread by construction.