# Accessing limited resources with Pthreads

I'm a Pthreads newbie and I've been giving myself a challenge: I want to have a resource that multiple threads can access at the same time as read. However, if a thread wants to write, then this need to be exclusive.

Now, I know that there are read/write locks designed specifically for this purpose. I would not do this in production code; this is just to learn. For simplicity, I assume there is only one thread that can write (but of course, multiple that read).

I have come up with two version. The first one does not use signals, the second one does. I tested it a little bit and both seem to work. However, multi-thread programming is tricky.

Could someone review the two versions and let me know whether there might be a bug that my tests missed?

Version 1

#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string>

class limited_resource
{
public:
limited_resource()
{
d_write_request = false;
}

virtual ~limited_resource()
{
}

{
// Do a stupid waiting
while(true)
{
if(!d_write_request)
{
break;
}

sleep(1);
}

char data[4];

for(int ii = 0; ii < 4; ++ii)
{
data[ii] = d_data[ii];
sleep(1); // Super slow reading to create bugs on purpose
}

// Decrement the number of readers
}

void write(const char *str)
{
d_write_request = true;

// Do a stupid waiting
while(true)
{
break;

sleep(1);
}

// Do the work
printf("Writing\n");
for(int ii = 0; ii < 4; ++ii)
{
d_data[ii] = str[ii];
sleep(1); // Super slow writing to create bugs on purpose
}

// Release the writing
d_write_request = false;
}

protected:

bool d_write_request;

char d_data[4];
};

limited_resource lr;

{

while(true)
{
}

return NULL;
}

int main(int argc, char **argv)
{
int N = 10;

int vals[N];

for(int ii = 0; ii < N; ++ii)
{
vals[ii] = ii;
}

char str[80];
while(true)
{
scanf("%s", str);
lr.write(str);
}

return 0;
}


Version 2

#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string>

class limited_resource
{
public:
limited_resource()
{

d_write_request = false;

}

virtual ~limited_resource()
{
}

{
// Wait
while(d_write_request)

char data[4];

for(int ii = 0; ii < 4; ++ii)
{
data[ii] = d_data[ii];
sleep(1); // Super slow reading to create bugs on purpose
}

// Decrement the number of readers
}

void write(const char *str)
{
d_write_request = true;

// Do a stupid waiting
while(true)
{
break;

sleep(1);
}

// Do the work
printf("Writing\n");
for(int ii = 0; ii < 4; ++ii)
{
d_data[ii] = str[ii];
sleep(1); // Super slow writing to create bugs on purpose
}

// Release the writing
d_write_request = false;
}

protected:

bool d_write_request;

char d_data[4];
};

limited_resource lr;

{

while(true)
{
}

return NULL;
}

int main(int argc, char **argv)
{
int N = 10;

int vals[N];

for(int ii = 0; ii < N; ++ii)
{
vals[ii] = ii;
}

char str[80];
while(true)
{
scanf("%s", str);
lr.write(str);
}

return 0;
}


## migrated from stackoverflow.comAug 28 '12 at 12:59

This question came from our site for professional and enthusiast programmers.

• This is a huge code dump. You're right for asking, because testing almost by definition won't find bugs in concurrency. But the answer to this is probably "take an OS class". As a quick and dirty answer, as long as you have one mutex per resource that you must obtain before writing, you won't have race conditions. But you could easily have problems with "starvation"; a thread that doesn't get to write ever, or "deadlocks"; where each is waiting for the other to give up a resource. People still don't know how to solve these generally, so you'd really need to study it properly to do it right. – Robert Nov 13 '11 at 1:13

You forgot to remove the "stupid waiting" from version 2. Otherwise, it looks good. Not particularly efficient, but correct.

You can and should remove this chunk of code from version 2. The code before it already does this:

    // Do a stupid waiting
while(true)
{
break;

sleep(1);
}


Here's an optimization for you. Change:

    if(d_nreading == 0)


to

    if( (d_nreading == 0) && d_write_request)


Reader/writer locks are based on the assumption that reading is frequent and writing is rare. So the common case would be that there's no writing. Your code makes an extra call into the pthread library for each read unlock, even that call is not needed.

• Both versions are definitely not correct. – Employed Russian Nov 13 '11 at 1:36
• @EmployedRussian Can you be just a bit more specific? (Perhaps you missed the problem statement that said it was okay to assume only one writing thread?) – David Schwartz Nov 13 '11 at 1:38
• On the contrary: the problem statement says "However, if a thread wants to write, then this need to be exclusive." Just like for reader/writer locks, this means multiple writers are not allowed simultaneous access, not that there could only exist a single writer. – Employed Russian Nov 13 '11 at 1:47
• @EmployedRussian I understood that to mean that a write lock means there are no outstanding (or new) read locks. "For simplicity, I assume there is only one thread that can write (but of course, multiple ones that read)." – David Schwartz Nov 13 '11 at 2:10
• Thanks everyone. I've written the version 3, which should support multiple writers. It seems OK so far. I've also added David's optimization; I tried to add it to write routine but it is not correct (it results in the program freezing up); search for "cannot be". Thanks again -- Tony – Antoine Bruguier Nov 14 '11 at 0:47

Both versions are buggy: they allow multiple writers in at once!

Consider what happens if there are no readers, and two writers call "write" at the same time. They will both set d_write_request to true, wait for readers to finish (there are none) and start writing at the same time.

Your testing conveniently neglects to test for multiple writers.

Also please don't call mutex a mutext. The mutex stands for "mutual exclusion", there is no T after E there.

• Ah, I missed that. Still, it's trivial to write code that doesn't make such simplifying assumption. I am not sure what OP stands to learn from "here is my simplified, inefficient implementation" (actually two imeplmentations) "of reader/writer lock that only solves half of the problem". – Employed Russian Nov 13 '11 at 4:22
• I agree. It's completely trivial to fix. It should at least, if nothing else, have code to assert in that case. – David Schwartz Nov 13 '11 at 4:33
• Thanks for your reply. It is not trivial to fix for me. I will give it a try. – Antoine Bruguier Nov 14 '11 at 0:46
• You could trivially fix it by just having the writer hold the mutex while it writes. – David Schwartz Aug 28 '12 at 13:47