Hi all
Charly suggested thread safe containers some weeks ago. I finally
found some time to try it, very much motivated by Jim W.'s Ruby
Conf talk :-P.
Please find my first implementation of a RWLock here
http://pastie.org/352321
All comments welcome, but I am particularly interested, if monitor.rb
or sync.rb have something to offer which might outperform
ConditionVariable#wait & #signal?
The algorithm itself is adapted from the 2nd edition of Java Threads
(Scott Oaks and Heny Wong, I always confuse him with Harry Kim 
Thanx in advance
Cheers
Robert
Hi all
Charly suggested thread safe containers some weeks ago. I finally
found some time to try it, very much motivated by Jim W.'s Ruby
Conf talk :-P.
Please find my first implementation of a RWLock here
http://pastie.org/352321
All comments welcome, but I am particularly interested, if monitor.rb
or sync.rb have something to offer which might outperform
ConditionVariable#wait & #signal?
The algorithm itself is adapted from the 2nd edition of Java Threads
(Scott Oaks and Heny Wong, I always confuse him with Harry Kim
Thanx in advance
Cheers
Robert
–
It is change, continuing change, inevitable change, that is the
dominant factor in society today. No sensible decision can be made any
longer without taking into account not only the world as it is, but
the world as it will be … ~ Isaac Asimov
On Mon, Jan 5, 2009 at 12:36 PM, Charles Oliver N.
[email protected] wrote:
Looks good to me at a glance, but obviously Mentalguy is probably the best
one to talk to about impls like this. Are you essentially interested in
porting the java.util.concurrent libraries? You could certainly choose a
worse candidate for porting…
Thanx but the contrary is true too, nevertheless that sounds like a
nice challenge. After all I know I can count on help if I am stuck :).
I’d love to see that whole set of collections
and locking primitives available in Ruby. They could probably be simplified
and condensed/combined a bit too.
I will have a look. I was disconnected from the Java World for a long
time, but since it is open source now my attitude changed radically
:).
But at first I will try to get out a wrapper for the containers.
they were pure native.
Well I had a look at monitor, that is just one level too high for what
we need here, so I guess CV are about the right tool, but I am still
listening…
Note that in all recent versions of 1.8, 1.9, and JRuby, the old “thread.rb”
library has been replaced with Mentalguy’s fastthread library, so at least
those items should be solid and speedy already.
Thanx for the feedback.
Robert
Robert D. wrote:
Hi all
Charly suggested thread safe containers some weeks ago. I finally
found some time to try it, very much motivated by Jim W.'s Ruby
Conf talk :-P.
Please find my first implementation of a RWLock here
http://pastie.org/352321
Looks good to me at a glance, but obviously Mentalguy is probably the
best one to talk to about impls like this. Are you essentially
interested in porting the java.util.concurrent libraries? You could
certainly choose a worse candidate for porting…I’d love to see that
whole set of collections and locking primitives available in Ruby. They
could probably be simplified and condensed/combined a bit too.
All comments welcome, but I am particularly interested, if monitor.rb
or sync.rb have something to offer which might outperform
ConditionVariable#wait & #signal?
I’d say both are candidates for porting into native code directly (C,
Java, etc). Given that people are more and more aware of how to do
threaded code in Ruby, and given that these libraries are often going to
be key to that effort, they really ought to be as screaming fast as
possible. The current implementations are probably not slow, but
definitely could be sped up if they were pure native.
Note that in all recent versions of 1.8, 1.9, and JRuby, the old
“thread.rb” library has been replaced with Mentalguy’s fastthread
library, so at least those items should be solid and speedy already.