I have a certain resource and two threads one is producer and the other one is consumer.
The producer update the resource every time interval and the update takes some time and I don't want the consumer to wait. I want his instead to work with the old values of the resource while the producer update.
How do I synchronize the two threads without putting the consumer to wait
You can have an atomic pointer through which the consumer reads what the producer produced. Once the producer generated new data, change the value of the atomic pointer to point to that new data instead.
The shared resource is going to have to be locked while it's being updated/read from. I guess the consumer could copy the resource into a buffer of its own? Or would that take just as long?
Related
I am trying to develop a program with POSIX threads in which i have a child thread which will be updating the content of a file and the database between certain intervals and there will be other children who reads data from the file and database all the time. So i don't want any thread to read the file or database while they are being written by the single updater thread. So my idea is to make all other children threads sleep from the child thread which will update the file and database. sleep() makes the calling thread sleep. Is there any way the above scenario can be implemented?!
EDIT:
I have two different functions for reading and writing the file. Most of the threads access the read method so they aren't vulnerable but they might be if they try to read in between while the periodic thread which accesses the write method is updating the file's contents.
You do not want to use sleep for this at all. Instead, use a reader/writer lock. The updater thread must acquire the lock (in write mode) before it modifies the data. And the other threads must acquire the lock (in read mode) before reading the data.
Note that if your reader threads are reading continuously, the writer will get starved and never acquire the lock. So you will need some separate mechanism such as a flag the updater can set that tells the readers to please stop reading and release their locks. If the readers only read occasionally this shouldn't be such an issue (unless there are tons of readers in which case you may have an architectural problem).
I am having really hard time understanding one issue in consumer producer problem for example in the below image which is about the simple structure of consumer:
My big problem is that in wait(mutex) and signal(mutex) the parameter mutex is the same for both so it makes sense that signal(mutex) wake up wait(mutex) process if it is blocked but in wait(full) and signal(empty) they pass different parameters so how signal(empty) can wake up wait(full)??????(it is noteworthy that we assume both full and empty are of type semaphore)
here is some more information that may help:
also the code for producer is:
The mutex semaphore handles avoidance of mutual access to some shared resource, the full and empty semaphores handle when producer and when consumer is allowed to run. It all depends on the setup of the semaphores but basically full should be set up to block on the first wait of the consumer, empty should be available on first wait in consumer.
The producer will then handle data and post on the full semaphore, which in turn will unblock the consumer task. Consumer will block on the next empty wait until producer posts the empty semaphore and so on until infinity or program end.
Any producer/consumer solution uses a buffer. Practical buffer implementations need to deal with the buffer having a finite size. It thus needs to solve two synchronization problems. One is the obvious one, the consumer needs to be blocked when the buffer is empty and woken up again when an item enters the buffer. The less obvious one is that producer needs to be blocked when the buffer is filled to capacity, unblocked when a consumer removes an item.
Two very distinct blocking operations that affect different pieces of code. It thus requires two semaphores.
This concept is purely based on synchronization. Note two important things:
1. About full and empty:
Producer can not produce if the buffer is full and the consumer can not consume if the buffer is empty. So, semaphore full and empty are used only to check this requirement. Please, refer to your text, the initial value for empty is n(size of buffer) and initial value of full is 0(no item for consumer yet).
Step I. Producer has wait(empty) to check if the buffer has space(only then produce).
Step II. It has signal(full) to confirm that it has successfully produced one more item. Consumer can consume it now.
Step III. Consumer has wait(full) to check if it can consume something or not as whenever producer will produce an item, he will confirm(through Step II).
Step IV. Consumer has signal(empty) to confirm that it has consumed one time and so, the buffer space is free.(again Step I).
2.About mutex: The mutex variable is only to ensure that at one time,only one process accesses the buffer. That's why Producer and Consumer both have wait(mutex) and signal(mutex). Whenever any process(be it producer or consumer) accesses buffer, it acquires mutex and when it leaves buffer, it releases mutex.
I have one sender thread and 40 worker threads. There is a single queue. All of the 40 threads write to the queue and the sender thread periodically reads from the shared queue and sends the data read over a tcp socket (say after every 1 sec, the sender thread must read data from the queue and send it over the socket). I have a question here:
If any of the 40 threads is in the critical section and all other threads are also waiting to enter the critical section and at the same time 1 sec timer is up and I want to ignore the requests of all other threads to enter the critical section, and the Sender thread must be given priority now and must be given the critical section.
In other words I want to set the priority of sender thread to 1 i.e. when sender thread calls EnterCriticalSection() then, all other threads that are waiting to enter critical section must be ignored and as soon as the critical section gets free, it must be given to the sender thread.
Is there any way to achieve this functionality?
You can not achieve it by using just priority, because if any of worker thread is holding a lock then priority can not force them to free it. Here is one implementation I can think off..
As soon as the sender thread will wake up after 1 sec duration it will send a signal to the worker process. And in the signal handler free the lock that is held by the workers(I guess a binary semaphore would be good here, so put it's value to 0 in the signal handler), so whatever worker thread will try to access it will get blocked. At sender side send all the packets and at the end again set semaphore back to 1.
This is one implementation, you can think think your own like that but eventually it should work .:)
You likely just want some variant of a reader-writer lock. And probably just a plain Win32 critical section lock is all that is needed.
Here's why. The operations in the critical section, append data to a queue (or reading from the queue), is a non-blocking operation. In other words, no operation on the queue will take longer than a fraction of a millisecond. If you use the Windows critical section lock (EnterCriticalSection, LeaveCriticalSection), fairness is guaranteed to threads waiting to enter the CS (I'm fairly certain of this).
So if all 40 writer threads need to enter the CS to append to the queue, that shouldn't take more than a millisecond or two for the reader thread to wait it's turn to acquire the lock. This is of course assuming that writer threads are only copying memory a queue and are not doing any long blocking I/O operations while having acquired the lock.
Hope this helps in solving your problem http://man7.org/linux/man-pages/man3/pthread_getschedparam.3.html
One of the possible solutions to Your issue lies in The way Threads are implemented in Linux. Try and have a Mutex. Let your Sender thread create a named FIFO (using mkfifo() call), And, when you create say 40 worker threads, in their respective functions, make them create a named fifo for receiving. Whenever your Sender thread wants to communicate with one of your Worker thread, use open() call to open the worker_fifo and write onto it, close it. But When you have things like a User-Client Application thing, Whenever you open a fifo, put a Mutex Lock, do whatever you want (read/write) and Unlock the Mutex when you are done with it.
While reading about binary semaphore and mutex I found the following difference:
Both can have value 0 and 1, but mutex can be unlocked by the same
thread which has acquired the mutex lock. A thread which acquires
mutex lock can have priority inversion in case a higher priority
process wants to acquire the same mutex whereas this is not the case
with binary semaphore.
So where should I use binary semaphores? Can anyone cite an example?
EDIT: I think I have figured out the working of both. Basically binary semaphore offer synchronization whereas mutex offer locking mechanism. I read some examples from Galvin OS book to make it more clear.
One typical situation where I find binary semaphores very useful is for thread initialization where the thread will read from a structure owned by the parent thread. The parent thread needs to wait for the new thread to read the shared data from the structure before it can let the structure's lifetime end (by leaving its scope, for instance). With a binary semaphore, all you have to do is initialize the semaphore value to zero and have the child post it while the parent waits on it. Without semaphores, you'd need a mutex and condition variable and much uglier program logic for using them.
In almost all cases I use binary semaphore to signal other thread without locking.
Simple example of usage for synchronous request:
Thread 1:
Semaphore sem;
request_to_thread2(&sem); // Function sending request to thread2 in any fashion
sem.wait(); // Waiting request complete
Thread 2:
Semaphore *sem;
process_request(sem); // Process request from thread 1
sem->post(); // Signal thread 1 that request is completed
Note: You before post semaphore in thread 2 processing you can safely set thread 1 data without any additional synchronization.
The canonical example for using a counted semaphore instead of a binary mutex is when you have a limited number of resources available that are a) interchangeable and b) more than one.
For instance, if you want to allow a maximum of 10 readers to access a database at once, you can use a counted semaphore initialized to 10 to limit access to the resource. Each reader must acquire the semaphore before accessing the resource, decrementing the available count. Once the count reaches 0 (i.e. 10 readers have gained access to, and are stil using the database), all other readers are locked out. Once a reader finishes, they bump semaphore count back up by one to indicate that they are no longer using the resource and some other reader may now obtain the semaphore lock and gain access in their stead.
However, the counted semaphore, just like all other synchronization primitives, has many use cases and it's just a matter of thinking outside the box. You may find that many problems you are used to solving with a mutex plus additional logic can be more-easily and more-straightforwardly implemented with a semaphore. A mutex is a subset of the semaphore, that is to say, anything you can do with a mutex can be done with a semaphore (simply set the count to one), but that there are things that can be done with a semaphore alone that cannot be done with just a mutex.
At the end of the day, any one synchronization primitive is generally enough to do anything (think of it as being "turing-complete" for thread synchronization, to bastardize that word). However, each is tailor-fit to a different application, and while you may be able to force one to do your bidding with some customization and additional glue, it is possible that a different synchronization primitive is better-fit for the job.
I wrote a simple program that implements master/worker scheme where the master is the main thread, and workers are created by it.
The main thread writes something to a shared buffer, and the worker threads read this shared buffer, writing and reading to shared buffer are organized by read/write lock.
Unfortunately, this scheme definitely leads to starvation of main thread, since a single write has to wait on several reads to complete. One possible solution is increasing the priority of the master thread, so if it wants to write something, it will get immediate access to the shared buffer.
According to a great post to a similar issue, I discovered that probably manipulating the priority of a thread under SCHED_OTHER policy is not allowed, what can be changed is the nice value only.
I wrote a procedure to give worker threads lower priority than master thread, but it seems not to work correctly.
void assignWorkerThreadPriority(pthread_t* worker)
{
struct sched_param* worker_sched_param = (struct sched_param*)malloc(sizeof(struct sched_param));
worker_sched_param->sched_priority =0; //any value other than 0 gives error?
int policy = SCHED_OTHER;
pthread_setschedparam(*worker, policy, worker_sched_param);
printf("Result of changing priority is: %d - %s\n", errno, strerror(errno));
}
I have a two-fold question:
How can I set the nice value of a worker threads to avoid main thread starvation.
If not possible, then how can I change the scheduling policy to a one that allows changing the priority.
Edit: I managed to run the program using other policies, such as SCHED_FIFO, all I had to do was running the program as a super user
You cannot avoid problems using a read/write lock when the read and write usage is so even. You need a different method. You need a lock-free message queue or independent work queues or one of many other techniques.
Here is another way to do the job, the way I would do it. The worker can take the buffer away and work on it rather than keeping it shared:
Write thread:
Create work item.
Lock the mutex or CriticalSection protecting the current queue and pointer to queue.
Add work item to queue.
Release the lock.
Optionally signal a condition variable or Event. Another option is for worker threads to check for work on a timer.
Worker thread:
Create a new queue.
Wait for a condition variable or event or other signal, or wait on a timer.
Lock the mutex or CriticalSection protecting the current queue and pointer to queue.
Set the current queue pointer to the new queue.
Release the lock.
Proceed to work on the now private queue.
Delete the queue when all work items complete.
Now write thread creates more work items. When all the worker threads have their own copies of a queue to work on it will be able to write many items in peace.
You can modify this. For example, a worker thread may lock the queue and move a limited number of work items off into its own internal queue instead of taking the whole thing.