Re:

faster than pthread mutexes. I am writing a (user code) OSSpinlock equivalent that uses a 1-byte (or 1-bit) flag rather than a 4-byte spinlock. And want to make it as fast as possible.

I'll echo Shantonu's (implicit) advice: whenever possible, use a locking mechanism the vendor (Apple in this case) provides. Why? 1. Users make mistakes, introducing bugs. If Apple's locking mechanism has a bug, it gets fixed fast and everyone using it benefits automatically. If your code has a bug, it takes longer to find/fix, and not all users get the fix as quickly as you'd like. 2. The performance gain is generally far, **far**, outweighed by the development cost. I.e., let's say you save a millisecond a day. If it takes 10 hours to code/debug/test/document your locking mechanism, you'll see the savings after about 78 thousand years. If you save a second a day, you'll see the savings after about one century. If you save a minute a day (which would be utterly astounding), you'll see the savings after about 2 years. I gave this same advice to HP-UX developers (and the HP-UX kernel lab) several decades ago, and it's still relevant :) The HP-UX kernel lab ignored it, and told developers the "best way" to write a user-level spinlock. Six months later, they were telling developers "oops", their published method was wrong :) Also, HP-UX developers who used a kernel supported mechanism found that it worked quite well when HP-UX moved from PA-RISC to Itanium, a move which made the assembly-level roll-your-own people rewrite their PA-RISC code. Does OS X have a good kernel supported locking mechanism that users can use? I don't know. It should. If it doesn't, lobby for one ... because that's the right way to improve the world for everyone :) Stan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com