The Art of Thread Synchronization?
kimo
http://wesnerm.blogs.com/net_undocumented/2005/04/the_art_of_thre.html
Jeffrey invented a super-fast thread synchronization lock,
SoaReaderWriterLock, that never puts any thread in a wait state. He
applied for a patent and sold the idea to Microsoft. Richter urged
Microsoft to relax restrictions to the use of the lock. Microsoft
agreed to allow the technique to developers of Windows application but
not other platforms like Linux.
His description of the lock was very impressive. The lock mechanism
works differently from traditionally block schemes which rely on the
try-finally mechanism. It is based on Service Oriented Architecture, in
which methods are called in a "Fire and Forget" manner. A delegate
is first passed to a Lock when it is first entered. The delegate is
either service immediately or sent to a reader or writers queue, where
it will later be dispatched to a threadpool. In effect, the application
becomes the scheduler instead of the operation system: After one
delegate executes, the next available one is called immediately without
any intermediate wait state.
The Wintellect site currently contains the PowerCollections library,
which works only on Whidbey, but Jeffrey Richter will soon be adding a
PowerThreading library as well to correct for the deficiencies in the
.NET Framework. The SOA lock will also be included with the
aforementioned restrictions.
Joe Seigh
Just saying the threads never go into a wait state isn't the same as
them never going into a wait state. What do you think the thread
that can't get the thread does?
Secondly, user level scheduling implies user level threads. Unless
the delegate code is understood to be able to run on another thread.
Basically the scheme just give a scheduling boost to the lock when
there is a queue of blocked threads to quickly eliminate the queue.
The less likely there is a queue, the less likely there will be
blocking which is what slows things down. I'd have to see how it
compares to an adaptive lock that allows queue jumping. Unless they
to an A B test, you have to take things with a grain of salt.
--
Joe Seigh
When you get lemons, you make lemonade.
When you get hardware, you make software.
Chris Thomasson
news:NvWdnV8V67UqB1nZ...@comcast.com...
Richter's Optex... OR any of Richter's sync primitives for that matter....
Humm... Any body have any comments?
:O
Here is a comment: Just use Alex's xchg based mutex... Much better...
:)
Chris Thomasson
news:1153724382....@p79g2000cwp.googlegroups.com...
>I wondered if this group has ever analyzed the claim here:
>
> http://wesnerm.blogs.com/net_undocumented/2005/04/the_art_of_thre.html
>
> Jeffrey invented a super-fast thread synchronization lock,
> SoaReaderWriterLock, that never puts any thread in a wait state. He
> applied for a patent and sold the idea to Microsoft. Richter urged
> Microsoft to relax restrictions to the use of the lock. Microsoft
> agreed to allow the technique to developers of Windows application but
> not other platforms like Linux.
I have not looked over the code yet. However, there is really no need to use
user level threads or any sort of read-writer lock in win32. Joe Seigh and I
have already had a discussion on implementing RCU-SMR with win32. Simple
technique actually. vZOOM runs on win32 in a somewhat similar fashion... So
IMHO, Richter's implementation of read-write functionary is overkill.
BTW kimo, sorry I did not get back to you with information on vZOOM.!.. I
was working hard on brushing up on and researching SPARC assembly language,
and getting vZOOM ready for SUN's CoolThreads contest... vZOOM lucked out
and is one of the first round finalists':
https://coolthreads.dev.java.net/
I was recently asked to speak to the press about vZOOM and the Contest, o
you might be able to read about vZOOM in a publication somewhere. Anyway, I
am planning on commercializing vZOOM after the Contest is completely over...
Chris Thomasson
They still need membars... So, IMHO, no matter what they do with read-write
"locks", RCU+SMR and vZOOM "like" algorithms will be "superior"... I would
like to see their algorithm efficiently scale to thousands of cores per
chip...
Chris Thomasson
>> I wondered if this group has ever analyzed the claim here:
>>
>> http://wesnerm.blogs.com/net_undocumented/2005/04/the_art_of_thre.html
>>
>> Jeffrey invented a super-fast thread synchronization lock,
>> SoaReaderWriterLock, that never puts any thread in a wait state. He
>> applied for a patent and sold the idea to Microsoft. Richter urged
>> Microsoft to relax restrictions to the use of the lock. Microsoft
>> agreed to allow the technique to developers of Windows application but
>> not other platforms like Linux.
>>
>> His description of the lock was very impressive. The lock mechanism
>> works differently from traditionally block schemes which rely on the
>> try-finally mechanism. It is based on Service Oriented Architecture, in
>> which methods are called in a "Fire and Forget" manner. A delegate
>> is first passed to a Lock when it is first entered. The delegate is
>> either service immediately or sent to a reader or writers queue, where
>> it will later be dispatched to a threadpool. In effect, the application
>> becomes the scheduler instead of the operation system: After one
>> delegate executes, the next available one is called immediately without
>> any intermediate wait state.
Okay. I "think" I see what he is doing... I "think" he is building
rw-"functionality" out of a thread-to-thread communication scheme based on
"queues and thread-pools"... In that case, yes, you would have control over
the "schedule", at some level.. I wonder about frequent context-switches...
There is a lot of talk of read-write queue and thread pools and
"dispatching"... This all has overhead, and implies switching... I could
probably cook something very similar up using virtually zero-overhead queues
from my library:
http://appcore.home.comcast.net/
Humm...