I'm calling you on "Caller Locks"
Posted Jul 3, 2009 17:30 UTC (Fri) by prl
Parent article: Linux kernel design patterns - part 3
Neil, thanks for your articles. I've been away, hence the late comment.
But... I want to call your bluff regarding locking. In part 2 you say:
If locking is needed, then the user of the data structure is likely to know the specific needs so all locking details are left up to the caller (we call that "caller locking" as opposed to "callee locking". Caller locking is more common and generally preferred).
and in the summary you state:
When there is any doubt, choose to have the caller take locks rather than the callee. This puts more control in that hands of the client of a function.
Hmm. Can you actually back up these assertions? Anyone reading the summary might assume that you have discussed this in the previous paragraphs, but it appears not. I don't think that being "more common" is a good recommendation; could you give us even just an LKML post which supports your claim that caller locking is "generally preferred"?
[ As an aside, I find the term "locking" in this kind of article problematic. Locking is one way to perform synchronisation, a very common way, true, but this leads people to refer to "locking" when they mean is generically "being SMP safe". ]
Do you necessarily want more control in the hands of a client? Surely it depends on the client. If we are talking about utilities used by drivers where the clients are written by hardware vendors struggling to get their first Linux contributions right, then you'll have a hard time convincing me. If a subsystem can handle all the sync it needs internally, clients don't need to worry about it at all, and the library developer can keep any eye on the best way to achieve this, as there are likely to be many more different configurations and usage patterns than such a client is likely to consider.
Here's one... given that the only real way that chip designers currently have to increase processor power is putting in more cores, I'm guessing that we'll see more architectures having more support for concurrency hardware. Subsystems which deal with their own syncing are likely to cope much better with using these variants as they become available.
Can I suggest that a better statement would be that callers need to better specify their synchronisation requirements, e.g. for performance or semantics, so that callees can better accommodate them. This may include a variant which explicitly means "Don't worry about sync, I already hold a lock", but that's just one form - and not one recommended for general use unless one really knows why..
to post comments)