29 thoughts on “Lab 5”

1. Dear prof, the link to the tar ball is forbidden. I think you need to set the permissions before we can download.

   • Thanks for letting me know. I have fixed it.

2. Dear prof, are we allowed to change the sequence of the pthread_create and pthread_join?

   • @Jie Sheng, How do you plan to change them?

     • Dear Prof,

       It is more like create the thread of the cook first then the savages.
       And joining the thread of the cook first then the savages too.

       • Yes you can, but it should not affect how you would solve the synchronization problem.

         • But it only work after I made the switch.
           Before, the cond signal seem to got lost.
           I think it is because we using cond instead of semaphore? Which does not keep track of the “number”?

           • This means that your solution depends on which threads run first. This should not be the case since you have no control over the order of thread execution, unless you synchronize them explicitly.

3. Hi Professor,

   When thread A have not execute the wait instruction and thread B sends a signal, will the signal be lost and A continue waiting?

   Thank you!

   • Yes, you are right. The signal will be lost.

4. Hi,

   Am I allowed to busy wait in the cook_process using a while loop? Otherwise there seems to be no other way to prevent the pot from overflowing.

   I will not reveal too many details here, but the order in which the threads are run does not allow savage threads to signal to the cook thread as the signal will be lost (at least initially).

   Thanks.

   • If you think it is absolutely necessary, yes, you can busy wait. (But there is no need and it is not efficient).

5. Hi Prof,

   from the question, it seems “If the pot is empty, the savage wakes up the cook and then waits until the cook has refilled the pot.” If there are cases of signal being lost, do we need to make sure that a savage only signals when the cook is waiting or can we use other methods to resolve cook signals being lost?

   Thanks!

   • You can use any methods you want to ensure that the signal is not lost (including checking if the cook is waiting before sending signal — but it’s tricky!)

6. Hi Prof,

   Will a test case whereby the number of servings is lesser than the number of savages be valid, e.g. savages 7 5 1?

   Thanks!

   • Yes. The cook just have to worked harder with a small pot.

7. Hi Prof,

   Is it okay if my program is slow, it took me about 30s to run savages 7 11 100 on sunfire.

   Thanks!

   • It’s OK, since the savage waits for up to .5 seconds after eating. You can change the input to usleep( ) to speed up your program for testing.

8. Hello, guys ,
   I encounter a weird problem which is,let’s say total refilling time is n, the program seems fine through the first n-2 iterations, but always ends up stucking in the (n-1)th iteration….
   Any one has the same problem

   • Are you using pthread_cond_wait to unlock a mutex at the start of the for loop in cook? If you are, the problem may be that the after the last refill the cook exits the for loop and hence doesn’t unlock the mutex with wait.

     • The cook process knew how many times it should loop to complete the savage request. Hence, i think putting cond_wait at the start of the for loop should not be the cause of this issue.

       • The thing is that the wait in savage and cook may be using the same mutex (at least they do in my code). This means that after signaling savage in cook you must unlock the mutex somehow (because wait will call lock on the mutex on return). Usually this job is done by the wait in cook, but on the last iteration its not, hence you need to explicitly unlock the mutex again outside the loop.

         • Thanks for your enlightening.
           It is a similar problem.
           It is because that cook still waits after final filling and no one wakes him up to join.

         • YES! this was exactly what was wrong lol Thanks alot

9. if we have only 1 savage, then savage and cook will wait. Is this normal, or we can fix it?

   • I don’t think it’s normal it possibly what you call a deadlock. Definitely can be fixed. You just need to ask yourself what is putting both threads to sleep at the same time.

10. Any hint on how to ensure that the savage who’s eating won’t be interrupted by another one until it eats k times?

    • If your for loop is in a critical region, then other savages cannot interrupt the loop.

      Note: As mentioned in the lab description, you are not supposed to make the savages eat k times one after another.

11. Dear professor,

    Do we have to take care of corner cases such as (0 0 0) or (1 1 0) or (0 1 1) and so on?

    If yes, what would be the output of (1 1 0)?

Comments are closed.