Home/ Questions/Q 6601073
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T18:42:21+00:00

I am developing a user level thread library as part of a project. I

  • 0

I am developing a user level thread library as part of a project. I came up with an approach to implement mutex. I would like to see ur views before going on with it. Basically, i need to implement just 3 functions in my library

mutex_init, mutex_lock and mutex_unlock

I thought my mutex_t structure would look something like

 typedef struct 
 {
   int available; //indicates whether the mutex is locked or unlocked
   queue listofwaitingthreads;
   gtthread_t owningthread; 
 }mutex_t;

In my mutex_lock function, i will first check if the mutex is available in a while loop. If it is not, i will yield the processor for the next thread to execute.

In my mutex_unlock function, i will check if the owner thread is the current thread. If it is, i will set available to 0.

Is this the way to go about it ? Also, what about deadlock? Should i take care of those conditions in my user level library or should i leave the application programmers to write code properly ?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This won’t work, because you have a race condition. If 2 threads try to catch the lock at the same time, both will see available == 0, and both will think they succeeded with taking the mutex.

    If you want to do this properly, and without using an already-existing lock, You must access hardware operations like TAS, CAS, etc.

    There are algorithms that give you mutual exclusion without such hardware support, but they make some assumptions that are many times false. For more details about this, I highly recommend reading Herlihy and Shavit’s The art of multiprocessor programming, chapter 7.

    You shouldn’t worry about deadlocks in this level – mutex locks should be simple enough, and there is some assumption that the programmer using them should use care not to cause deadlocks (advanced mutexes can check for self-deadlock, meaning a thread that calls lock twice without calling unlock in the middle).

    • 0