Smalltalk › Squeak › Croquet › Croquet - Dev

Message queues: TIsland vs TIslandController

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Tapple Gao

Message queues: TIsland vs TIslandController

I don't understand the relationship between TIsland and
TIslandController. Why do both of them have a message queue and
a current time?

It seems to me that TIsland should have no notion of time, and
just be a message queue, while TIslandController knows about
time and releases messages to the TIsland when it needs them

Or something like that.

What is the purpose of each?

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

Andreas.Raab

Re: Message queues: TIsland vs TIslandController

Matthew Fulmer wrote:
> I don't understand the relationship between TIsland and
> TIslandController. Why do both of them have a message queue and
> a current time?

Actually TIslandController doesn't have a current time. However, it
utilizes its own event loop because there is so much concurrent
interaction going on that it's easier to synchronize it by scheduling it
via its own event loop. That event queue is entirely unrelated to the
islands' queue.

> It seems to me that TIsland should have no notion of time, and
> just be a message queue, while TIslandController knows about
> time and releases messages to the TIsland when it needs them

That's exactly what the controller does. The TIsland needs its own
notion of time though since it must be able to schedule internal future
messages.

Cheers,
- Andreas

Tapple Gao

Re: Message queues: TIsland vs TIslandController

On Tue, Jul 08, 2008 at 06:07:10PM -0700, Andreas Raab wrote:

> Matthew Fulmer wrote:
> > I don't understand the relationship between TIsland and
> > TIslandController. Why do both of them have a message queue and
> > a current time?
>
> Actually TIslandController doesn't have a current time. However, it
> utilizes its own event loop because there is so much concurrent
> interaction going on that it's easier to synchronize it by scheduling it
> via its own event loop. That event queue is entirely unrelated to the
> islands' queue.
>
> > It seems to me that TIsland should have no notion of time, and
> > just be a message queue, while TIslandController knows about
> > time and releases messages to the TIsland when it needs them
>
> That's exactly what the controller does. The TIsland needs its own
> notion of time though since it must be able to schedule internal future
> messages.
>
> Cheers,
> - Andreas

It seems to me that time should be seperated from the event
queue. I think it should work like this:

A TIsland has a priority queue of messages to be executed. The
Island can be started, stopped, or stepped at any time. A
TIslandController would use this low-level mechanism to
implement time, stepping the island until the time of the next
message is greater than the goal time. Messages, both internal
and external, would pass through the controller to recieve their
priority

This would also allow other messaging policies to be plugged in,
such as a simple fifo executer, that allowed all messages to run
as fast as possible in the case that no inter-island
synchronization is needed.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

Andreas.Raab

Re: Message queues: TIsland vs TIslandController

This is exactly how it works. The island's event queue is a priority
queue of messages, sorted by time. TIsland methods like #decode:,
#scheduleMessage:at:, and #advanceTo: can be used to deliver, schedule
and execute messages up to any time you'd like to. TIslandController and
friends use this API to "run" the islands by controlling the flow of
time coming from the router. It is utterly trivial to write a little
loop that executes all outstanding messages right away but it is also
utterly pointless ;-) A more realistic thing to try is to run the
messages based on the local wall clock which TLocalController does.

And just in case you are wondering why this is being factored into the
various controllers instead of subclassing TIsland - that's because you
can't snapshot an image segment for replication with all that crap in it ;-)

Cheers,
- Andreas

Matthew Fulmer wrote:

> On Tue, Jul 08, 2008 at 06:07:10PM -0700, Andreas Raab wrote:
>> Matthew Fulmer wrote:
>>> I don't understand the relationship between TIsland and
>>> TIslandController. Why do both of them have a message queue and
>>> a current time?
>> Actually TIslandController doesn't have a current time. However, it
>> utilizes its own event loop because there is so much concurrent
>> interaction going on that it's easier to synchronize it by scheduling it
>> via its own event loop. That event queue is entirely unrelated to the
>> islands' queue.
>>
>>> It seems to me that TIsland should have no notion of time, and
>>> just be a message queue, while TIslandController knows about
>>> time and releases messages to the TIsland when it needs them
>> That's exactly what the controller does. The TIsland needs its own
>> notion of time though since it must be able to schedule internal future
>> messages.
>>
>> Cheers,
>> - Andreas
>
> It seems to me that time should be seperated from the event
> queue. I think it should work like this:
>
> A TIsland has a priority queue of messages to be executed. The
> Island can be started, stopped, or stepped at any time. A
> TIslandController would use this low-level mechanism to
> implement time, stepping the island until the time of the next
> message is greater than the goal time. Messages, both internal
> and external, would pass through the controller to recieve their
> priority
>
> This would also allow other messaging policies to be plugged in,
> such as a simple fifo executer, that allowed all messages to run
> as fast as possible in the case that no inter-island
> synchronization is needed.
>

Tapple Gao

Re: Message queues: TIsland vs TIslandController

On Tue, Jul 08, 2008 at 06:38:47PM -0700, Andreas Raab wrote:
> This is exactly how it works. The island's event queue is a priority
> queue of messages, sorted by time. TIsland methods like #decode:,
> #scheduleMessage:at:, and #advanceTo: can be used to deliver, schedule
> and execute messages up to any time you'd like to. TIslandController and
> friends use this API to "run" the islands by controlling the flow of
> time coming from the router. It is utterly trivial to write a little
> loop that executes all outstanding messages right away but it is also
> utterly pointless ;-)

Well, that is exactly what I want to do. I want to use islands
to handle parallel computation, like a higher-level MPI.
Computation is timeless. I am working on how to demo this by
writing a parallel raytracer using islands as the units of
parallism.

It would also be useful to have a controller that released
messages under user controll, so that islands could be stepped,
one message at a time, like the Tweak debugger can do, except
with an entire island.

I guess it's just a simple matter of programming.

> A more realistic thing to try is to run the
> messages based on the local wall clock which TLocalController does.
>
> And just in case you are wondering why this is being factored into the
> various controllers instead of subclassing TIsland - that's because you
> can't snapshot an image segment for replication with all that crap in it ;-)

TIslandControllers do not run inside an island, as they are
external to the island abstraction.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

Andreas.Raab

Re: Message queues: TIsland vs TIslandController

Matthew Fulmer wrote:
>> It is utterly trivial to write a little
>> loop that executes all outstanding messages right away but it is also
>> utterly pointless ;-)
>
> Well, that is exactly what I want to do. I want to use islands
> to handle parallel computation, like a higher-level MPI.
> Computation is timeless. I am working on how to demo this by
> writing a parallel raytracer using islands as the units of
> parallism.

I see. In this case I would probably recommend that you don't fiddle
with the time base and merely use internal futures without explicit
delta time. Those will be scheduled in the current time slot which means
that all of your processing runs effectively at a single point in time
but if you come to the point where you want to do some algorithm
animation you can do that 'cause you haven't thrown out the time base
yet ;-)

> It would also be useful to have a controller that released
> messages under user controll, so that islands could be stepped,
> one message at a time, like the Tweak debugger can do, except
> with an entire island.

Right. That should be fairly straightforward.

Cheers,
- Andreas

sathyas

Re: Message queues: TIsland vs TIslandController

hi i'm sathya

u have any example application ( using croquet).........................

thks