AFAIK, the mutex API was introduced to the kernel after LDD3 (Linux device drivers 3rd edition) was written so it's not described in the book.
The book describes how to use the kernel's semaphore API for mutex functionality.
It suggest to use down_interruptable() instead of down():
You do not, as a general rule,
want to use noninterruptible operations unless there truly is no alternative. Non-interruptible operations are a good way to create unkillable processes (the dreaded
“D state” seen in ps), and annoy your users [Linux Device Drivers 3rd ed]
Now. here's my question:
The mutex API has two "similar" functions:
mutex_lock_killable() an mutex_lock_interruptable(). Which one should I choose?
Use mutex_lock_interruptible() function to allow your driver to be interrupted by any signal.
This implies that your system call should be written so that it can be restarted.
(Also see ERESTARTSYS.)
Use mutex_lock_killable() to allow your driver to be interrupted only by signals that actually kill the process, i.e., when the process has no opportunity to look at the results of your system call, or even to try it again.
Use mutex_lock() when you can guarantee that the mutex will not be held for a long time.
Related
I am writing the Windows port for a Linux application and I am trying to find a suitable replacement for pthread_cond_wait(). The closest alternative seems to be SleepConditionVariableCS(). However I am unwilling to use this function because it uses CriticalSections which are basically lightweight recursive mutexes. I would prefer a non-recursive lock object alternative - is there one?
P.S. -
In the application in place of pthread mutexes I am using Semaphores with maximum count 1.
If recursive mutexes are as problematic as stated by David Butenhof then why does Windows provide only recursive Mutexes (or CriticalSection) as an option? Is this a massive #Fail on part of Windows or is David Butenhof outdated/wrong?
Windows Vista and later provide Slim Reader/Writer (SRW) Locks as a non-recursive lock object alternative 1.
As the documentation states:
An SRW lock is the size of a pointer. The advantage is that it is fast to update the lock state. The disadvantage is that very little state information can be stored, so SRW locks cannot be acquired recursively. In addition, a thread that owns an SRW lock in shared mode cannot upgrade its ownership of the lock to exclusive mode.
A Windows Condition Variable can use a SRW lock instead of a CriticalSection lock. See SleepConditionVariableSRW().
1: PS. Here's another view on the good vs. bad of recursive locks .
I made an example that writes into process memory using task_for_pid() and mach_vm_write().
task_for_pid(mach_task_self(), pid, &target_task);
mach_vm_write(target_task, address, '?', local_size);
Is there a way to block to access memory of the specific process from another processes like cheat engine on OS X.
How do I prevent another process from calling task_for_pid?
Not that many others come to mind except hooking.
In OS X, the calls to task_for_pid are regulated by taskgated. Basically, unless it's your task , or you're root (or, in older systems, member of procview group), you won't get that elusive task port. But if you are allowed, then you have the port, and can do basically anything you want.
Hooking won't help, since task_for_pid is a mach trap - people can call it directly using the system call interface. iOS has much tighter controls on it (thanks to AppleMobileFileIntegrity.kext). If you want to control the trap, effectively the only way of doing so is writing a small kext to do the trick for you.
I am writing a simple character device driver. (kernel 2.6.26)
Multiple concurrent reader & writers are expected.
I am not sure what type of lock is best used to synchronize a short access to internal structures.
Any advice will be most appreciated
Compare with http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/c214.html . An old document from before when mutexes existed, but given mutexes are a sleeping lock, they count towards user context.
spinlock — spinlock_bh — mutex — semaphore
If your data structures are only ever accessed by functions whose execution is triggered by userspace, all lock primitives are available to you. It depends on gut feeling of how short a "short access" is.
And then there is RCU as a fifth way of doing things, though it is somewhat not a locking primitive in its own right. (It is used together with one of the lock primitives.)
Start with a mutex. Once you've got it working you can think about reworking the locking.
I am using Radio Layer Interface (RIL) Native APIs in Windows Mobile application. In this API, the return values / results of most functions are not returned immediately but are passed through a callback function which is passed to the RIL API.
Some usage examples are found at XDA Develompent Tools and Google Gears Geolocation API.
My question is, in these two examples, a mutex is used to guard the data instead of other synchronization objects.
Now, will Critical Section do fine here in the use cases described by both examples? Which thread or process will actually call the callback functions?
Edit:
My data is accessed by my codes only from inside my process but which thread/process is calling the callback functions in RIL API? I mean, I passed a function callback to the RIL API, but are the callbacks called from other process? in that case, it will give another explanation why the samples are using Mutex. If the RIL API actually creates a thread inside my process and it calls my callback functions, then I think Critical Section would be fine (and it's faster than a mutex).
Update:
I have data which is (1) accessed by my codes from within my own process and is also (2) modified from a function callback. The callback is done by RIL API.
My Question: Which thread/process is calling the callback functions in RIL API?
The Story so far:
Me: Hi Mr RIL, please put some data into my office (a.k.a variables).
RIL: OK Sir. I will put the data later and I will signal you when it is done (I used an event here).
An access card is required to enter my office. If Mr RIL is from the same company as me, Mr RIL can use his own access card to enter my office (in my case, it means a Critical Section). If he is from other companies, I will need to set up an access card/visitor card for him (in my case, I need a mutex here).
If Mr RIL uses his own access card, it means I don't need to set up an access card/visitor card for him and that means less trouble for me. (i.e. Critical Section is faster than a Mutex)
The problem is, I just met this Mr RIL a few days ago and I don't know much about him. I don't know if he is from the same company as me. One option as mentioned by nobugz is to set up an access card for Mr RIL regardless whether Mr RIL is from the same company as me. This way, Mr RIL is guaranteed to be able to enter my office. (my data/variables are guaranteed to be safe)
Right now I use mutex in my code (set up a possibly redundant access card for Mr RIL).
Aha! Just got an idea when writing this. I think I will just ask Mr RIL from which company he is. That way, I don't have to set up access card for him in the future if he turns out to be in the same company as me. (i.e. put GetCurrentProcessId() and GetCurrentThreadId() in the callback function)
The Windows Mobile RIL normally resides in device.exe (for WM6.x). However, when your process invokes the RIL, your call passes via the RIL Proxy.
The RIL proxy is linked with, and resides in your process, and handles all of the issues associated with process boundaries for you (as an aside, this is at least part of the reason why all RIL data structures need to be packed into a single block of memory of known size). Internally the RIL Proxy creates a thread on which your callback is executed.
This means that your code can use a CRITICAL_SECTION object to provide the necessary synchronization/protection.
The point of using the mutex is that you don't know what thread might make the callback. Yes, a critical section would work too. Careful, getting it wrong causes random and very hard to diagnose failure.
A critical section is a mutex. A critical section is different from a normal mutex (at least primarily) in one way: it's specific to one process, where a mutex can be used across processes.
So, in this case, the basic question is exactly what you're protecting -- if it's the data inside your program, that won't be accessible to another process, then a critical section should do the job nicely. If you're protecting something that would be shared by the two processes if the user were to run two instances of your program at once, then you probably need a mutex.
Edit: As far as having to use a critical section to protect what RIL itself does, no, that isn't (or at least definitely shouldn't) be needed. With a mutex, you're counting on all the processes cooperate by opening a mutex with the same name to control access to the shared resource(s). You can't count on that, so if it is needed the interface is completely broken.
Update: unless they're doing something really unusual in RIL, the callback will happen within your process, so a critical should be adequate. If it's modifying your data, that means your data is mapped and visible to that code -- which means the data in the data in the critical section will also be mapped and visible, and it'll work. The time a critical section doesn't work is when you're dealing with separate processes, so the data in one isn't mapped/visible to the other.
Well, one other difference between a mutex and a critical section (Windows implementations, of course) is that a critical section is re-entrant - i.e. the same thread can acquire the critical section twice without having to release it.
I need a lock in cocoa that does not use one cpu when I try to lock it and it is locked somewhere else. Something that is implemented in the kernel scheduler.
It sounds like you're trying to find a lock that's not a spin lock. EVERY lock must use some CPU, or else it couldn't function. :-)
NSLock is the most obvious in Cocoa. It has a simple -lock, -unlock interface and uses pthread mutexes in its implementation. There are a number of more sophisticated locks in Cocoa for more specific needs: NSRecursiveLock, NSCondition, NSDistributedLock, etc.
There is also the #synchronized directive which is even simpler to use but has some additional overhead to it.
GCD also has a counted semaphore object if you're looking for something like that.
My recommendation is that, instead of locks, you look at using NSOperations and an NSOperationQueue where you -setMaxConcurrentOperationCount: to 1 to access the shared resource. By using a single-wide operation queue, you can guarantee that only one thing at a time will make use of a resource, while still allowing for multiple threads to do so.
This avoids the need for locks, and since everything is done in user space, can provide much better performance. I've replaced almost all of my locking around shared resources with this technique, and have been very pleased with the results.
Do you mean "lock" as in a mutex between threads, or a mutex between processes, or a mutex between disparate resources on a network, or...?
If it's between threads, you use NSLock. If it's between processes, then you can use POSIX named semaphores.
If you really want kernel locks and know what you are doing, you can use
<libkern/OSAtomic.h>
Be sure to always use the "barrier" variants. These are faster and much more dangerous than posix locks. If you can target 10.6 with new code, then GCD is a great way to go. There is a great podcast on using the kernel synchronization primitives at: http://www.mac-developer-network.com/shows/podcasts/lnc/lnc032/