[HW Help] C++/Linux/Pthreads

EPIK

Veteran XX
I'm not going to mask this as anything but what it is... a homework help thread. I'm also not asking for anyone to give me the answer but to instead maybe point me in the right direction.

That said, here's my issue.

I'm attempting to write a C++ program that creates 15 threads, then accesses some shared resources. Problem is, I'm having trouble coming up with a good mechanism for synchronizing the threads so that each thread has a quasi-equal opportunity at hitting the shared resource (no deadlock/livelock).

I've got several google links, but at this point could use some peer to peer discussion over the topic. I've written the program thus far to create the threads and access the shared resource using a mutex... However, the method I'm doing it is laughable and leading to several threads never accessing the shared resource.

The main problem is for each thread to grab numbers from a pool of numbers from 0-999999 until the shared pool of numbers is exhausted.

The code I have thus far is on a VM, so I will copy and paste it here shortly unless no one shows any interest in assisting me. :[

Thanks in advance.
 
I don't know C++ that wll but in C# we'd probably use a static object to lock on to prevent deadlocks using the lock command. There are better, more complicated ways, (autoresetevents come to mind) but I can't imagine using them for a homework assignment like this. Sorry if this doesn't port to C++
 
How quasi-equal an opportunity is this supposed to be? Can you make a process/thread responsible for scheduling the other ones that makes it so that get exactly the same amount of resources?
 
Use a 'critical section'.

Critical section - Wikipedia, the free encyclopedia

Basically if you're about to access something only one thread can use at once, use pthread_mutex_lock( &cs_mutex ); and then _unlock() when you're done with it.

If you've locked the critical section (in this case, cs_mutex) any other threads trying to obtain the lock 'wait' at that code line until the mutex is released via unlock().

In the above example, 'cs_mutex' is an instance of a critical section - you can have more than one if you want to have more than one lock (eg to protect a different resource).

An example:

void Increment_Counter()
{
// Enter the CS
pthread_mutex_lock( &cs_mutex );

// Perform our work
_counter++;

// Leave/release the CS
pthread_mutex_unlock( &cs_mutex );
}
 
Last edited:
How quasi-equal an opportunity is this supposed to be? Can you make a process/thread responsible for scheduling the other ones that makes it so that get exactly the same amount of resources?

No constraints on how I implement the synchronization. Each thread doesn't need to get equal amount of numbers, but I have several threads not getting any numbers at all.
 
Give me just a moment and I'll paste the code on a site... Damn VM isn't wanting to let me get the code off of it.
 
You might be able to affect locking/queueing semantics by playing with pthread_mutex_attr; I can't remember.
 
You might be able to affect locking/queueing semantics by playing with pthread_mutex_attr; I can't remember.

I believe this is what I need.

Rayn, the problem is that all the threads can't information from the shared resource.

Okay, virtualbox is a bitch. I'm used to VMware.
 
Just because you create X amount of threads doesn't mean they all get something.

The CPU scheduler may not have gotten around to waking the thread yet because the others had already done all of the work.

Add a sleep() call in the 'work' method you have each thread do (to simulate some 'real work' being done) and you should hopefully see each thread having a chance to do some of the work.
 
No constraints on how I implement the synchronization. Each thread doesn't need to get equal amount of numbers, but I have several threads not getting any numbers at all.

In an actual system, this isn't really a problem. If you have 15 identical threads trying to access a shared resource and only 10 of them are pulling numbers out, it just means you don't really need 15 threads for the task.
 
Back
Top