Find the answer to your Linux question:
Results 1 to 5 of 5
Hi , I have written an application which has more than 6 threads. Two threads share a common linked list. Out of two threads one thread reads the linked list ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Nov 2006
    Location
    Harrisburg, PA, USA
    Posts
    56

    Question Accessing shared data between threads using mutex


    Hi ,

    I have written an application which has more than 6 threads.
    Two threads share a common linked list. Out of two threads one thread reads the linked list node and other thread writes to linked list node.

    I am using pthread_mutex_lock() API to achieve synchronisation between having access to common linked list. The problem is the first thread which reads the linked list accesses the mutex faster making other thread to starve.

    I want both the thread to have an access to mutex. It should not happen that always first thread locks, releases and relocks it. The first thread almost require to access the link list every 5 msec which is causing second thread not to gain the mutex.

    How should I fix this? For information, I am running this application on PXA270 ARM platform.

    Thanks in advance.

    Regards,
    Sumit

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,556
    This sort of race condition is not uncommon in multi-threaded applications. In your case, as I understand it, the (mostly) reader accesses the thread often enough to starve the other (mostly) writer from updating the list. A mutex may not be your best solution in this case. You could try an inter-thread signal where the writer signals the reader to stop reading the list until the writer is done updating it, which then signals the reader when done with the update so that the reader can re-traverse the list to continue it's reading operation. If it wasn't reading the list when the signal arrived, then it can simply continue on. Usually in such a situation, the writer will also set a mutually accessible variable that indicates an update is going on, so if the reader wasn't actively reading the list upon receiving the signal, it can look at the variable when it does need to access the list, and wait until it is unset before continuing. Anyway, this isn't simple code, but often necessary in such situations. There are other methodologies to use as well, but this isn't the place to get into such. I've had to teach classes on this subject, so I know exactly what complexities are involved.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined!
    Join Date
    Nov 2006
    Location
    Harrisburg, PA, USA
    Posts
    56
    Got it.

    If I don;t put a mutex on reader process, while writer can write data at any time, will it corrupt the shared data? Or reader will get an old data?

    Thanks.

    Regards,
    Sumit

  4. #4
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,556
    As long as there is only one writer of the data, there won't be any corruption. Depending upon what the writer is doing, it may or may not interfer with the reader. For example, if the writer removes a node from a linked list and deletes (frees) it, then the reader will (not so) happily cause a core dump. That is why I mention the need for some sort of syncronization between writer and reader, in order to avoid this type of situation. A signal of some sort can be handled by the reader thread so that it will stop reading, and continue in some sort of sane fashion when the writer is done. To model such operations I strongly recommend the use of a finite-state-machine model, even if only on paper, to validate your system behavior. Most UML modeling tools these days have decent state-machine diagramming tools which help tremendously in resolving these sort of situations. I use them all the time myself, and have been for over 20 years in the design and development of complex real-time distributed systems.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  5. #5
    Just Joined!
    Join Date
    Nov 2006
    Location
    Harrisburg, PA, USA
    Posts
    56
    I agree with you.

    I would acquire a mutex to have synchronization between reader and writer process to access shared link list. This way there would not be a problem of writer process deleting a node and reader process trying to access it.

    Thanks.

    Regards,
    Sumit

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •