On Oct 18, 2006, at 10:53 AM, Carl Smith wrote:
Thanks so much for the reply.
You answered my main question now you raise a new question for me.
If I want to protect code critical regions, is there a different method I should be using instead of lck_mtx_lock, or do I have to worry about each and every data object that I am processing?
Without a detailed analysis of your code, I really can't help you here; you need to look at how you use the various data objects, and understand what hazards you need locking to protect against.
When starting from scratch, I like to consider what the "atomic" operations are that the code performs; an index lookup, or updating the status of some piece of work by manipulating fields in a datastructure, and then find a place where I can put a lock such that it is in scope for any thread that might be performing this operation.
This does also force you to structure your code in a modular and data-oriented fashion, as locking imposes some substantial constraints on what assumptions you can make about the contents of a datastructure if you don't hold a lock on it.
I guess in retrospect I could some direction where to read up on the 10.4 locking design. If anyone knows where I could find this document and or some examples I would appreciate it.
You will find many examples in the Mac OS X kernel sources for 10.4, which are available from the usual places.
There isn't a document as such, and in your specific instance a document on how an overall design philosophy was applied to some other code might not help very much.
You might want to start by picking up a decent book on user-space thread programming. Whilst the details of the interfaces vary, the challenges involved in synchronising operation between multiple concurrent threads in a single data context are very similar, and such a book will almost certainly spend some time discussing the major approaches to lock architecture.
= Mike