You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

Why and how to use condition variables? - Pthreads

Q: What is a condition variable?A: A condition variable is a variable of type `pthread_cond_t`. It is
used to suspend the thread execution until some condition is true.

Q: Is a condition variable dependent on a mutex lock to work properly? Why?A: Explaining with an example:

Assumptions:

There is a variable `x` whose current value is 0.

There is a thread `threadA` whose task is to start some job once the
variable `x` reaches the value 1000.

There is a thread `threadB` whose task is to keep on incrementing the
variable `x`'s value until it reaches 1000, and then send a signal
for the threads waiting for this variable's value to turn 1000.

Possible problematic situation:

Scheduler schedules the thread `threadA`.

Now, the thread `threadA` checks the value of variable `x` and finds
that it hasn't yet reached 10. The thread `A` is now supposed to wait
(by calling a particular pthread function) till that variable's value
reaches 10.

Scheduler schedules the thread `threadB`.

Thread `threadB` increments the variable `x` changing its value to 10,
and then calls the pthread function responsible for signaling the end
of waiting period for thread `threadA`.

Scheduler schedules the thread `threadA`.

Thread `threadA` (unaware of the thread `threadB`'s deeds) now starts
waiting for the variable `x` to change its value to 10. The signals of pthread do _not persist_. The thread `threadA` will now wait forever for
the signal that has already come and gone.

Solution to the above situation:
We need to write a condition such that the thread `threadA` acquires the mutex lock _before_ checking the value of the variable `x` and
releases it after waiting or deciding not to wait on the condition
variable.

Because the thread `threadA` locks the Mutex _before_ performing the critical
activities (checking the variable's value and then waiting/not-waiting
on the condition variable), the `thread B` simply can't change the
variable's value and or send a signal till the `thread A` unlocks the mutex it
held.

This code demonstrates the solution for the above problem attained by using
the mutex lock.