Hi Wink,

 I'm the guy that presented the Robotic Underwater Marine Laboratory at
rubyconf2005 and, yes, I'm quite interested in the lightweight messaging
approach
you describe.  In fact, I cobbled together a very similar threading
library framework
for our application.  It is a very common technique for real-time
systems programming,
after all.

We push all the real-time constraints down to firmware coded on custom
microcontrollers in 'C', so I've never had much cause to look at the
performance
of the Ruby's threading scheduler.  It's "adequate" for a dozen or so
threads on
a 200Mhz ARM9.  However, we are looking at Ruby for other applications where
we won't have the luxury of throwing a bunch of microprocessors at problem.

Soooo:

I'd like to review and help you test your O(1)ish scheduler in the hopes
that we might convince the core maintainers to accept it.

- brent

> Subject:
> Threading performance
> From:
> Wink Saville <wink / saville.com>
> Date:
> Tue, 25 Oct 2005 16:06:39 +0900
>
> To:
> ruby-core / ruby-lang.org
>
>
> Hello all,
>
> I would like to first apologize in advance for posting to the core as
> a newbie, but this seems like the right place. Anyway, I'm interested
> in adding light weight asynchronous messaging to Ruby. My idea is to
> create messaging components which are composed of a thread and a queue
> with messages are sent between components via the Queue. This allows
> for significant parallelism but decreased issues thread safety issues
> as each message is processed by the component one at a time. Of course
> any shared objects would have thread safety issues, but if a component
> only operates on its own objects the issues should be significantly
> reduced. Currently we have implemented a similar system in C for a
> consumer audio product and it has worked OK, but I would like to use a
> higher level language and Ruby looks like a good. But performance is a
> concern, especially since we are using 100MHZ ARM7's.
>
> Anyway, I've done a trial implementation and noticed that the as I
> increased the number of messaging components the number of messages
> per second was dropping. So I look into why and have done some
> measurements using the following program:
>

.... snip ....

> Soooooooo:
>
> 1) What are the issues using  _THREAD_SAFE for cygwin?
>
> 2) If I were to create a more efficient implementation of
> rb_thread_schedule, shooting for O(1), would that be interesting to
> anyone?
>
> 3) To do a more efficient implementation I've already taken the first
> step and split eval.c into 4 files eval.h, thread.c and thread.h, is
> anyone interested in these files? Of course they would need to be
> evaluated by some experts and probably changed, but I think
> refactoring out the threading code makes sense. Note: Evan originally
> suggested this to me when we talked at the Ruby Conference.
>
> 4) Is anyone interested in a light weight asynchronous messaging for
> Ruby? By light weight I mean the performance decrease due to message
> passing is low (use binary for marshaling) and by asynchronous I mean
> that sending a message never blocks nor returns a value. Messages are
> placed on a queue that the receiver will processes at a time of its
> choosing.
>
> Cheers,
>
> Wink
>
>

-- 
 Brent Roman                                   MBARI
 Software Engineer               Tel: (831) 775-1808
 7700 Sandholdt Road,         Moss Landing, CA 95039
 mailto:brent / mbari.org  http://www.mbari.org/~brent