Re: thread priority ?

Hi,

Sam wrote:
>It seems to me that a low priority process being able to lock out a high priority process
>is a sign of poor application design
It's not poor design, it's the essence, the true nature of locks.

>(there should be a way for the high priority process to tell the low priority one
>to release the lock immediately).
Well, there is, but then you're not really into locks anymore and
entering another paradigm, e.g. transactional memory.
The key insight is that if you want to force a release, the "recipient" must be
prepared for that situation. Traditional locks do not know about that.
The typical solution is some rollback, either manually or automatically.

There's interesting current discussion about the design of restartable sequences
(at the user-level) in Linux, whose goal is "atomic" updates encompassing many
instructions. This needs OS support, but a distinguishing requirement is again, that
there be some user-level code to properly handle the restart, i.e. that
knows how to back off in case of conflict.
https://lwn.net/Articles/697979/

Some non-Intel processor (ARM? RISC? can't remember) has a pair of HW instructions to
the effect of starting and ending some kind of transaction on shared memory. I found that
very interesting and stimulating the day I read about it. It is amenable to many more
different scenarios than the traditional (and predefined) atomic "compare and swap",
"exchange", "test and set", "increment or add" instructions and, what makes it
especially interesting in my eyes, I expect that to scale much better than those
atomic monolithic instructions to machines with many cores.
I (as programmer) consider those traditional atomic instructions to be lock-less and very
efficient, however, at the HW level, they are *much* more expensive than a straight
read or write, because they require synchronization across all caches; they are not lock-less
at the HW level at all.
On the contrary, the above pair of HW instructions looks to me very similar to
"optimistic locking" in databases: extremely efficient in the majority of cases
where there's no contention, IMHO indeed as efficient as a straight read/write.

>I don't think one can fix it with some OS-level policy.
I don't understand that belief.
For example, the OS could kill the low-priority thread holding a lock. Why not?
But that would require an Erlang-style system construction, not the typical
heavy-weight, resource and state intensive threads.
May be the kill is easier for you to envision with processes (mutex) instead of threads,
since taking down a process is expected to take care of associated resources and state.
Process-mutexes are prepared/designed for the situation that one process dies.
Take down an unprepared thread, and another thread is likely to hang a little later,
indirectly waiting for the killed thread via some kind of synchronization variable or post
condition that will never hold.

Regards,
	Jörg

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
clisp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-list