[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Actors and Concurrency

fedzor

2/11/2008 11:18:00 PM

So I was messing with actors today, and I found that I couldn't get
an actor to run concurrently with the main thread. Am I just wishing
fibers are something they're not?

I had:

Actor.spawn
sleep 1
puts 5
end

puts 6

and it went:
5
6

So what do I have to do to get Actors to go concurrent on my ass? I
was hoping for:
6
5

Thanks,
Ari
--------------------------------------------|
If you're not living on the edge,
then you're just wasting space.



5 Answers

MenTaLguY

2/12/2008

0

On Tue, 12 Feb 2008 08:18:03 +0900, fedzor <fedzor@gmail.com> wrote:
> So I was messing with actors today, and I found that I couldn't get
> an actor to run concurrently with the main thread. Am I just wishing
> fibers are something they're not?

To a point. However, note that if you want an actor to sleep for one second
and permit other actors to proceed, you can just receive with a timeout of
one second, rather than using sleep. Receive is how revactor actors transfer
control to one another.

Of course, if the main thread exits (as it would in your code), then the
spawned actor won't have a chance to finish.

-mental



Jason Roelofs

2/12/2008 12:01:00 AM

0

(others can get more specific here, but here's the general idea)

First of all, Ruby does not have concurrency. Not even 1.9 allows
concurrently running threads. The Ruby VM is a preemptive kernel.
Eventually Ruby's threads will be system threads *and* fully
concurrent, but that's a long time from now.

Second, Actors aren't really threads or Fibers. There's a single
"dispatcher" thread/process/whatever that handles sending out events
to the pool of actors. So while Actors may look like threads and
concurrency, they aren't.

So put the two together, and you're going to get sequential code execution.

Jason

On Feb 11, 2008 6:18 PM, fedzor <fedzor@gmail.com> wrote:
> So I was messing with actors today, and I found that I couldn't get
> an actor to run concurrently with the main thread. Am I just wishing
> fibers are something they're not?
>
> I had:
>
> Actor.spawn
> sleep 1
> puts 5
> end
>
> puts 6
>
> and it went:
> 5
> 6
>
> So what do I have to do to get Actors to go concurrent on my ass? I
> was hoping for:
> 6
> 5
>
> Thanks,
> Ari
> --------------------------------------------|
> If you're not living on the edge,
> then you're just wasting space.
>
>
>
>

MenTaLguY

2/12/2008 12:10:00 AM

0

On Tue, 12 Feb 2008 09:00:38 +0900, "Jason Roelofs" <jameskilton@gmail.com> wrote:
> Second, Actors aren't really threads or Fibers. There's a single
> "dispatcher" thread/process/whatever that handles sending out events
> to the pool of actors. So while Actors may look like threads and
> concurrency, they aren't.

Not necessarily true. Different actor implementations may have different
scheduling behavior. For example, if you're using actors from the Omnibus
library, you get a thread per actor, each of which handles its own event
processing. On JRuby, that means you get a native thread per actor.

On the other hand, a native thread per actor isn't a good way to achieve
performance.

-mental


fedzor

2/12/2008 2:13:00 AM

0


On Feb 11, 2008, at 6:59 PM, MenTaLguY wrote:

> On Tue, 12 Feb 2008 08:18:03 +0900, fedzor <fedzor@gmail.com> wrote:
>> So I was messing with actors today, and I found that I couldn't get
>> an actor to run concurrently with the main thread. Am I just wishing
>> fibers are something they're not?
>
> To a point. However, note that if you want an actor to sleep for
> one second
> and permit other actors to proceed, you can just receive with a
> timeout of
> one second, rather than using sleep. Receive is how revactor
> actors transfer
> control to one another.
>
> Of course, if the main thread exits (as it would in your code),
> then the
> spawned actor won't have a chance to finish.

Can you give me some example code of working with receive? I kind of
understand, but feel like some code would really nail it in.

Thanks,
Ari
-------------------------------------------|
Nietzsche is my copilot



fedzor

2/12/2008 2:14:00 AM

0


On Feb 11, 2008, at 7:00 PM, Jason Roelofs wrote:

> (others can get more specific here, but here's the general idea)
>
> First of all, Ruby does not have concurrency. Not even 1.9 allows
> concurrently running threads. The Ruby VM is a preemptive kernel.
> Eventually Ruby's threads will be system threads *and* fully
> concurrent, but that's a long time from now.
>
> Second, Actors aren't really threads or Fibers. There's a single
> "dispatcher" thread/process/whatever that handles sending out events
> to the pool of actors. So while Actors may look like threads and
> concurrency, they aren't.
>
> So put the two together, and you're going to get sequential code
> execution.

I understand that there isn't really *true* concurrency, but is there
any possible way to get, for example, my previous program to print "6
\n5" instead of "5\n6"? I was hoping for some sort of Thread-like
concurrency, but apparently am just wishing.


~ Ari
English is like a pseudo-random number generator - there are a
bajillion rules to it, but nobody cares.