Spin locks should be employed in conjunction with real-time
scheduling policies (SCHED_FIFO, or possibly SCHED_RR). Use of spin
locks with nondeterministic scheduling policies such as SCHED_OTHER
probably indicates a design mistake. The problem is that if a thread
operating under such a policy is scheduled off the CPU while it holds
a spin lock, then other threads will waste time spinning on the lock
until the lock holder is once more rescheduled and releases the lock.
If threads create a deadlock situation while employing spin locks,
those threads will spin forever consuming CPU time.
User-space spin locks are not applicable as a general locking
solution. They are, by definition, prone to priority inversion and
unbounded spin times. A programmer using spin locks must be
exceptionally careful not only in the code, but also in terms of
system configuration, thread placement, and priority assignment.
There is a lot to unfold in the manpages. See lsof.
A lesson for us all to actually look at the documentation.
But I find that it's easy to miss to read them for some reason, we rather read one SO response instead (that eventually lead straight back to the manpage). Which is interesting in itself. Must we invent the wheel all the time rather than using the shipped documentation? Or am I alone in falling in that trap?
> Must we invent the wheel all the time rather than using the shipped documentation?
I think it's a matter of accessibility, it is a reasonable assumption that someone writing code wants to consult the entire internet thus if the relevant manpages are not indexed by search engines then they won't find the documentation. Doing minimal SEO and publishing sitemaps is quite important. I've seen way too many institutions wondering the same question "Why are people reinventing the wheel?" when the answer is that simply having a website is not enough to be reachable.
$ man -k spin
pthread_spin_destroy (3) - initialize or destroy a spin lock
pthread_spin_init (3) - initialize or destroy a spin lock
pthread_spin_lock (3) - lock and unlock a spin lock
pthread_spin_trylock (3) - lock and unlock a spin lock
pthread_spin_unlock (3) - lock and unlock a spin lock
TAP::Parser::Scheduler::Spinner (3perl) - A no-op job.
Sigh... you really don't understand how much preliminary knowledge and prerequisites it takes to "simply" issue that command. With this answer you demonstrate exactly the mindset why so much information is behind some obscure knowledge and pointlessly so. "I know it's there means others know it's there" sigh...
Not to mention that ~95% of the Earth's population doesn't speak English as the first language, how stuff is named in English is not obvious. Bad search engines, like what `man -k` has, are nearly unusable if you don't know the exact term. You'd laugh when people would recommend to you to look up words using a paper dictionary or write papers using paper encyclopedias but `man -k` is pretty much that.
To be fair, this is one of the toughest lessons for all.
It makes total sense to those who know it by heart, but at the same time it makes no sense to those who honestly don't. The line between is pretty hard.
Also, this is what makes me believe there is room for more discoverability-commands in Linux-land CLI. Especially for diagnostics. Since those developing it have a hard time seeing the same from a beginner point of view.
The guy is a professional dev working on Linux, are you seriously suggesting he shouldn't know what "man" does? And are you seriously suggesting that searching for "spin" is somehow arcane?
pthread_spin_lock(3) is on the first page, along with a RH presentation which explains exactly why trying to roll your own userspace implementation is unlikely to be successful. The guy simply didn't do his homework, I have no idea why you are trying to defend him.
When you know the correct keywords it's easier to search that way.
I wonder everyday how I teach my colleuges how they should learn more about linux. My best attempt so far is to skim the man pages of at least coreutils rpm. That and TLDP.
It's like knowing Google Fu, much is in finding useful keywords.
http://man7.org/linux/man-pages/man3/pthread_spin_init.3.htm...
Spin locks should be employed in conjunction with real-time scheduling policies (SCHED_FIFO, or possibly SCHED_RR). Use of spin locks with nondeterministic scheduling policies such as SCHED_OTHER probably indicates a design mistake. The problem is that if a thread operating under such a policy is scheduled off the CPU while it holds a spin lock, then other threads will waste time spinning on the lock until the lock holder is once more rescheduled and releases the lock.
If threads create a deadlock situation while employing spin locks, those threads will spin forever consuming CPU time.
User-space spin locks are not applicable as a general locking solution. They are, by definition, prone to priority inversion and unbounded spin times. A programmer using spin locks must be exceptionally careful not only in the code, but also in terms of system configuration, thread placement, and priority assignment.