I'm assuming this has been asked on here, but I can't find this particular question. Does it just lock the part of the code in between the lock and unlock, or does it lock global variables? Like for this code
pthread_mutex_lock(&mtx);
bitmap[index] = 1;
pthread_mutex_unlock(&mtx);
the mutex just locks that line of code? Is there a way to lock specific variables without just locking the part of code that uses them?
No, it locks the actual mutex variable.
Any piece of code that attempts to lock that mutex while it's locked will block until it's unlocked.
If that is the only piece of code that locks the mutex then, yes, you can say it just protects that line. But that's not necessarily the case.
A mutex is used to serialise access to a resource. Whether that resource is considered a line of code or (more likely in this case) the bitmap array is down to where the mutex is locked and unlocked.
Chances are you have a few different areas where the bitmap array is read or modified and you should probably ensure they're all protected by the mutex.
No there is no way to just lock a variable.
Mutex is just an abstraction. So whenever you want some variable should not be affected when you are working on it, declare a mutex for that variable and lock it as long as you want.
There is no direct relation between the mutex and the variable you want to lock. Its up to the programmer. Most commonly it is used in multi-threaded environment.
Whenever a variable (a resource. In programming, resources are manipulated in variables) is shared across parallel running processes (according to kernel, threads of a same process are a group of processes sharing same address space and some resources), if a programmer want to make the variable to be accessed exactly only one process at a particular time, he has to write the block of code accessing the variable in all the processes (or threads) between a mutex lock pair (pthread_mutex_lock and pthread_mutex_unlock). So whenever the variable is accessed in any process (or thread), mutex will be locked. So if another process want's to access the variable, it has to wait until the mutex unlock. So the programmers' final goal is achieved.
Related
I want to release the lock I've acquired within the main process and hand it over to a specific thread. Is there a way I can do this? I'm using the pthreads library
I want to release the lock I've acquired within the main process and hand it over to a specific thread.
This implies that multiple threads want to acquire this lock.
If it matters which one of these threads actually gets it, your design is very likely wrong.
Is there a way I can do this?
No.
I use process shared pthread_mutex_t on shared memory. I wonder what if a process lock the mutex and somehow exit, what will happen? As my experiment shows, deadlock happens, but this is a bad news. So is there a way to prevent this? Should not the mutex automatically unlocked when process exit?
No, the mutex shouldn't be automatically unlocked, because the shared data protected by the mutex may be in an inconsistent state.
If you want to handle this situation, you need to use "robust mutexes". To create a robust mutex, set the mutex robustness property to PTHREAD_MUTEX_ROBUST by using pthread_mutexattr_setrobust() on a pthread_mutexattr_t object that is used to initialise the mutex.
If a thread or process exits while holding a robust mutex, the next call to pthread_mutex_lock() on that mutex will return the EOWNERDEAD error. If this error is returned, your code must carefully check all the shared state protected by the mutex and fix any inconsistencies. It can then mark the state as consistent by calling pthread_mutex_consistent() on the mutex, and then continue its execution as normal.
I am using an Audio Output Unit to capture mic data. I get notified that there is data to read via a callback I have set using the kAudioOutputUnit_SetInputCallback property, and in the callback I read the data by calling AudioUnitRender().
Ultimately, I will be updating the user interface of my app on the basis of some information extracted by analysing this data. I will therefore need at some stage to do a dispatch_async onto the main queue. The analysis is moderately time consuming, and is done in chunks rather larger than those I get from AudioUnitRender(), so the load is bursty.
My question is: what operations are considered acceptable in the implementation of the input callback itself? I've found plenty of sources stating strict restrictions on render callbacks (no memory allocations, no i/o, no synchronisation with other threads, etc), but no information at all about input callbacks.
If I follow the same rules as for render callbacks, I have a bit of a challenge. dispatch_async() itself is undesirable as it allocates memory, and the load is bursty anyway (could easily be longer than one render cycle on some turns, and practically zero on others). It therefore seems necessary to send my data off to a worker thread for processing and for the dispatch_async() calls to be made. However, I still need to manage the passing of the data over to this worker thread. The simplest way (in C++) would be with a circular buffer, plus a mutex and condition variable to signal when data is available. However, that would require the input callback to lock the mutex, which the guidelines on render callbacks explicitly discourage.
Avoiding this mutex lock will take me to lock-free circular buffers, semaphores (POSIX or GCD), spinlocks and the like, and I'm wondering if that is overkill for simply listening to a microphone. There's a shocking lack of documentation for this stuff and I have no idea what's really going on behind the scenes. Do I really need to be concerned about waiting on a mutex (only briefly and rarely locked by another thread) in my input callback implementation?
I use a circular buffer from: https://github.com/michaeltyson/TPCircularBuffer
The description states:
As long as you restrict multithreaded access to just one producer, and just one consumer, this utility should be thread safe.
So you can both render (produce) and process (consume) from the circular buffer safely without worrying about locks.
Update:
Do I really need to be concerned about waiting on a mutex (only briefly and rarely locked by another thread) in my input callback implementation?
To that I say yes. "Rarely locked" is all you need for an input callback to fail. And "briefly" is already too long. I had input callbacks fail simply for NSLogging something.
I am trying to write a customized threadpool suited to my purpose using pthreads, and I am new to pthreads. I read these (POSIX threads programming and Linux Tutorial Posix Threads) tutorials online and they were quite helpful, but i still have some (maybe silly) doubts regarding mutexes and condition variables:
What is the scope of a mutex? Will a global mutex lock all the global variables so that only one thread can access them at a time? If i have two global mutexes, would they lock the same set of variables? What about a mutex that is declared inside a class or a function, what will happen when i lock/unlock it?
If i just plan to just read a global variable, and not modify it at all, should i still use a mutex lock?
If i am correct, a condition variable is used to wake up other threads which are sleeping (or blocked using pthread_cond_wait()) on some condition. The wake up call to sleeping threads is given by pthread_cond_signal() or pthread_cond_broadcast() from some other thread. How is the flow of control supposed to occur so that some all or one thread wake(s) up to do a work and wait until next work is available? I am particularly interested in a scenario with 4 threads.
Is there a way to set the affinity of a thread to a particular processor core before it is created (so that it starts execution on the desired core and no shifting of cores occur after creation)?
I am sorry if the questions look silly, but as i said, i am new to this. Any help, comments, code or pointer to good resources is appreciated. thanks in advance for your help.
That's a lot of questions. A few answers.
(1a) The scope of a mutex is whatever you program it to be. In that sense it is no different from any other kind of variable.
(1b) A global mutex will protect whatever variables you program it to protect. I think from your other questions you might have a fundamental misunderstanding here. There is nothing magical about mutexes. You can't just declare one and say "Ok, protect these variables", you have to incorporate the mutex in your code. So if you have two functions that use variable X and one does a mutex lock/unlock around any changes to the variable and the other function completely ignores that a mutex even exists you really aren't protecting anything. The best example I can think of is advisory file locks - one program can use them but if another doesn't then that file isn't locked.
(1c) As a rule, don't have multiple mutexes locking the same data. It is an invitation to problems. Again the use of mutexes depends on programmed cooperation. If function A is protecting data B with mutex C while function D is protecting data B with mutex E then data B isn't protected at all. Function A can hold the lock on mutex C but since function D pays no attention to it it will just overwrite data B anyway.
(1d) Basic scoping rules apply.
(2) No. If the variable isn't going to change in any way that would make it inconsistent among threads then you don't need to lock it.
(3) There are a number of detailed answers on this on SO that go into considerable detail on this. Search around a bit.
(4) Not that I am aware.
Here's the situation, I have a thread running that is partially controlled by code that I don't own. I started the thread so I have it's thread id but then I passed it off to some other code. I need to be able to tell if that other code has currently caused the thread to block from another thread that I am in control of. Is there are way to do this in pthreads? I think I'm looking for something equivalent to the getState() method in Java's Thread class (http://download.oracle.com/javase/6/docs/api/java/lang/Thread.html#getState() ).
--------------Edit-----------------
It's ok if the solution is platform dependent. I've already found a solution for linux using the /proc file system.
You could write wrappers for some of the pthreads functions, which would simply update some state information before/after calling the original functions. That would allow you to keep track of which threads are running, when they're acquiring or holding mutexes (and which ones), when they're waiting on which condition variables, and so on.
Of course, this only tells you when they're blocked on pthreads synchronization objects -- it won't tell you when they're blocking on something else.
Before you hand the thread off to some other code, set a flag protected by a mutex. When the thread returns from the code you don't control, clear the flag protected by the mutex. You can then check, from wherever you need to, whether the thread is in the code you don't control.
From outside the code, there is no distinction between blocked and not-blocked. If you literally checked the state of the thread, you would get nonsensical results.
For example, consider two library implementations.
A: We do all the work in the calling thread.
B: We dispatch a worker thread to do the work. The calling thread blocks until the worker is done.
In both cases A and B the code you don't control is equally making forward progress. Your 'getstate' idea would provide different results. So it's not what you want.