| |||||||||||||
|
| |||||||||||||
Documenting and enforcing locking requirementsDocumenting and enforcing locking requirementsPosted Jul 19, 2002 18:58 UTC (Fri) by Lorenzo (guest, #260)Parent article: Documenting and enforcing locking requirements
In the topic: Documenting and enforcing locking requirements ... the paragraph: As was discussed last week, one problem with an increasingly fine-grained kernel is that it becomes difficult to know which locks, out of thousands,must be held at any given point. Some functions include documentation on their locking requirements (and sometimes it's even current), but many others don't. And there is no way for the code to actually enforce those requirements. ... just sends shivers down my spine at the complete misunderstanding by the author of fundamental principles of locking. To wit: "Some functions include documentation on their locking requirements ...". The whole concept of "locking code" is broken as designed. One should lock data, not code. It is the data that is vulnerable to concurrent access and update, not the code. Once an engineer/programmer grasps that fundamental concept, the problem becomes more manageable. Thanks. I feel much better now.
(Log in to post comments)
Documenting and enforcing locking requirements Posted Jul 20, 2002 14:53 UTC (Sat) by corbet (editor, #1) [Link] I hate to say it, but your author is not entirely clueless.In this case, there are many kernel functions that expect to be called with specific locks already held. Yes, the lock is protecting data (or hardware resources, etc.), but the function needs to have access to said data. If a function tries to take out a lock that the thread already holds, it will spin for, shall we say, a very long time. There could also be a problem with lock ordering requirements. Thus, "locks held" is part of the interface to a Linux kernel function whether you like it or not.
Documenting and enforcing locking requirements Posted Jul 21, 2002 23:40 UTC (Sun) by Lorenzo (guest, #260) [Link] Good programming practice also suggests that you should never leave a function while holding a lock. ... but, you do what you have to do.
|
|
||||||||||||