I want to check for correct mutex - mutex

Question

I just want to check answer that i think is correct.
Process producer {
while(1) {
// produce c
lock(empty);
lock(mutex);
data = c;
unlock(mutex);
unlock(full);
}
}
Process consumer {
while(1) {
lock(full);
lock(mutex);
c = data;
unlock(mutex);
unlock(empty);
// consume c
}
}
how many mutex are in use?
i think pthread_mutex_t empty , mutex, full;
three mutexes are used here.
what is the initial state of the mutexes?
I have no idea about this. What is the initial state of mutex?
Here is another example of mutex
Process producer {
while(1) {
lock(mutex);
if (count == 0){
// produce c
data = c;
count = 1;
}
unlock(mutex);
}
}
Process consumer {
while(1) {
lock(mutex);
if (count == 1){
c = data;
count = 0;
}
unlock(mutex);
// consume c
}
}
In my power point, the problems for this code are produced inside of lock and busy wait, but I think it is good. When something enters in the producer function or consumer function, it has mutex lock and escape them unlocked.
what is wrong?

Answer 1

For the first part:
Yes, the pseudocode uses three mutexes.
If you have no idea, what is the initial state of a mutex, perhaps you should read more about mutexes, here or here or in your course materials (this looks like a school exercise).
But to answer it briefly: When your program (the part of it that uses mutexes) starts, the mutex can be locked or unlocked. Here, you use 3 mutexes:
mutex to make sure only one producer or consumer is accessing data at the same time
empty to make sure producers will only get to produce if the storage (represented by data) is empty
full to make sure consumers will only get to consume if the storage is full
When this code starts, you:
Do want to allow one of the producers/consumers to do something => mutex must be unlocked.
Do want a producer to produce something - assuming your storage is empty in the beginning => empty will be unlocked.
Do not want any consumer to start consuming (until a producer has produced something) => full will be locked.
For the second part:
Well, your power point is right. This code has, well, exactly the issues it says it has.
First, it has the code that produces c inside the lock. That code is represented by a comment here, but it is usually something that takes time. During the time one of your threads is producing c, all others will have to wait on the lock (instead of possibly doing something useful).
Second, it has active waiting. What happens if there are 10 producers and 1 consumer and something was already produced? The only one who could actually do something is the consumer, so it would be nice for the producers to stand in the corner and wait. But guess what - they will all compete for the lock and it may take a very long time before the consumer wins and gets into the critical section.
To make it clear, it will work (your comment on it is right). It's just super uneffective and will waste your CPU time.