|
|
Log in / Subscribe / Register

Axiomatic validation of memory barriers and atomic instructions

Axiomatic validation of memory barriers and atomic instructions

Posted Aug 26, 2014 8:05 UTC (Tue) by jzbiciak (guest, #5246)
In reply to: Axiomatic validation of memory barriers and atomic instructions by PaulMcKenney
Parent article: Axiomatic validation of memory barriers and atomic instructions

I think I missed that article the first time 'round. Thank you for linking it.

FWIW, on "future work" item #3, it seems like unconditional lock acquisition is equivalent to either:

  • A function with a return value that says that you acquired the lock (and just always happens to be 'true'), or
  • A function with a while-loop around a call to a conditional lock acquisition function that spins until the lock is actually acquired.

Those two statements actually say the same thing under the hood—that there's a fundamental step with a return value (whether you acquired the lock) and a composite step that repeats the fundamental step until a goal is achieved (you actually acquired the lock).

To tease this apart in the SNC framework, it seems like you need some additional criterion to determine whether your measurement point for SNC-ness is at the appropriate level, or that you must drill down.

In this case, the execution time of "unconditional lock acquisition" can not be bounded because it depends on the state of the lock and the behavior of the other lock holders, and so represents SNC communication. (In this case, to the CPU's conditional branch circuitry.) That suggests a potential criterion stated in terms of the termination condition for the API. If the termination condition that allows the API to exit is SNC, the API is SNC.

At least, that's my initial gut feel after reading that article.


to post comments

Axiomatic validation of memory barriers and atomic instructions

Posted Aug 26, 2014 8:22 UTC (Tue) by jzbiciak (guest, #5246) [Link] (1 responses)

Minor clarification. On this point:

the execution time of "unconditional lock acquisition" can not be bounded

I'd like to add "... on the basis of the inputs to the lock acquisition API alone."

Basically, I was trying to capture the idea that if some code tries to take a lock unconditionally, the lock-taker's execution time is almost entirely at the mercy of the lock holder regardless of how clever the lock-taker's algorithms are. You cannot progress until the lock holder releases the lock.

And, of course, if multiple threads try to take the lock simultaneously, other threads may win ahead of this one, so the identity of "lock holder" may change during the process of attempting to acquire the lock. I don't think that changes the idea I'm attempting to express.

Stating these ideas precisely is simultaneously necessary and difficult. :-)

Axiomatic validation of memory barriers and atomic instructions

Posted Aug 26, 2014 15:12 UTC (Tue) by PaulMcKenney (✭ supporter ✭, #9624) [Link]

Indeed, this stuff is not easy. Ten years from now, when all the details are worked out, it will probably seem a lot easier, but of course other problems will arise in the meantime. (Where would be the challenge otherwise?)

Believe it or not, in some special cases, the execution of lock acquisition can be bounded. I briefly cover this in a blog post (http://paulmck.livejournal.com/37329.html), and Bjoern Brandenburg analyzed it in depth in his dissertation (http://www.mpi-sws.org/~bbb/papers/index.html#thesis). Surprising, perhaps, but true!

Nevertheless, your original statement that lock acquisition cannot be bounded is correct in the not-uncommon case of non-FIFO locking primitives and potentially unbounded critical sections (e.g., waiting for a network packet to arrive while holding a lock). Even with FIFO locking primitives, the upper bounds for lock can grow extremely large as the number of threads increases, as the permitted lock nesting levels increase, and as the number of real-time priority levels in use increases.

Nevertheless, it is worth noting that locking does not necessarily imply unbounded execution times.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds