Broadcasting

[Kyle Lahnakoski]

Jason Marshall wrote:
> 
> ><preamble>
> >
> >One thing that I have noticed about myself is that I will speak as if
> I
> >am talking of implementation.  I am not.  I usually talk in terms of
> an
> >apparent model.  This model, technically, has nothing to do with
> >implementation.
> 
> Interface frequently suggests a default implementation, but rarely
> dictates it.

That is an issue for the compiler/IDE.  I have no IDE, and my compiler
is simple.

> 
> >Function instances (also called Messaging State Machines) are objects
> >that are executable.  In C a function instance is the stack space a
> >function would use and the space taken for temporary variables.  It
> >would not include the executable code, that is a "function"  Please
> see
> >http://www.arcavia.com/rd/dbc-html/Function.html for a better
> >explanation.
> 
> You've just described a stack frame, or an activation record, yes?
> 
> >Function instances, in DBOS, have a single context variable.  A
> context
> >variable is much like a stack except it has a maximum and minimum size
> >of one.  I can not seem to get rid of the context variable.  This does
> >not bother me anymore.
> 
> Care to elaborate here?

Context variables are used to hold the implied parameters for function
calls.  In stack based systems, all parameters are implied.  In C there
are almost no implied parameters.  Each C call has an implied name
space, #defines and conditions.  Let us consider the following function
call.

	a.MyFunction(name="Kyle", age=26);

In MSM code (Messaging State Machine code) we have:

	GetValue(object=Primary_Key, field=a);		(1)
	MyFunction(name="Kyle", age=26);		(2)

The GetValue function takes the variable a, a puts its value on to the
context variable.  MyFunction expects an object to be on the context
variable and sends it the MyFunction message.  I could expand the
parameter listing for the MyFunction() and do the following:

	MyFunction(this=a, name="Kyle", age=26);

Again, I have implied that "a" is a field of the current object.

	MyFunction(contextobject=this, this=a, name="Kyle", age=26);
		 
Now, in this example, we have removed the need for a context variable. 
But there are many times that deep references are needed.  Here is an
example of a single linked list.  I must look far enough ahead to be
able to delete an object

	if (this.next.next.object==removeMe){...

In Object Code we write:
	
	CompareObject(Value1=This.next.next.object, Value2=removeMe);

In MSM code the above is expanded to (assume 'a' is a local var):

	Primary_Key;		//put This into context var 
	GetValue(object=next, field=next);
	GetValue(object=contextvar, field=object);
	SetValue(object=Primary_Key, field=a);
	CompareObject(value1=a, value2=removeMe);

I hope that is clearer.



GetValue assumes that the field references are part of This.  I am like
the format for GetValue now because it is very similar to a variable.  A
variable has  two attributes, they distinguish it uniquely from all
other variables, and they are the object.field pair.  GetValue appears
to requesting the value of a specific variable that has the object.field
attribute pair.  But I do notice that GetValue can be streamlined into
two functions.  Currently there are three ways to use the GetValue
function:

	GetValue(object=Primary_Key, field=<fieldname>);
	GetValue(object=contextvar, field=<fieldname>);
	GetValue(object=<fieldname1>, field=<fieldname2>);

The last one can put in terms of the first two:

	GetValue(object=Primary_Key, field=<fieldname1>);
	GetValue(object=contextvar, field=<fieldname2>);

With only two methods of using GetValue, we can make two single
parameter functions called GetLocalValue() and GetContextValue().  Maybe
I will do that, but it does not resolve the context variable issue.


> 
> >Broadcasting:  What is it?  How should it be modeled?
> >
> >Consider yourself an object.  Currently, to get work done, you send
> >messages to other objects.  Semantically, I chose:
> >
> >       destination Object.MyMessage(Name="Kyle", Age=26);
> 
> As I recall, Smalltalk also makes the distinction of treating all
> method
> calls as messages.  This makes some sense when you consider that
> the language is dynamically typed, and so you can add or delete
> message handlers (methods/interfaces) at runtime.  I'm not aware of
> the multicast mechanism, but my knowledge of the language is limited.

Objective C also uses the messaging.  I like to use "broadcasting"
instead of "muticasting" because the former implies the work of message
passing is done by the receiver, and the latter implies the work done by
the sender.


> >Each object has a message queue, and messages can be blocking or non
> >blocking. There is no semantic model to distinguish the two yet.
> 
> Well, let me ask you this question:  Are you set on implementing this
> feature
> at the language level, or is it sufficient to do so in your standard
> libraries?

I am not to sure I know what you mean.  I would like the semantics of
broadcasting to be different than the semantics of unicasting.  Right
now, logically, broadcasting is an instruction that has global scope. 
If this instruction is a library instruction, or part of hard code (hard
code is the name of source code in any language but Object Code) has
very little distinction.  If you mean to have global broadcasting
objects, objects that perform the work of broadcasting, I do not like
that.  Broadcasting, to me, only has two object speakers and listeners;
there is no third transport mechanism that is an implementation detail.



> That, of course, would clearly semantically differentiate the two, and
> that
> seems to be the path most languages take to achieve multicast
> messaging.
> Of course, the problem there is when you leave a dangling reference to
> a
> logically dead object, so maybe forcing the user to keep a clean
> reference

I do not know what you mean by logically dead object.  Do you mean
listening to an object that will never speak?  If you are, then yes,
that that is a problem that is not solved yet.  But if you mean an
object that does not exist then the object that models the listening
connection will also disappear through regular garbage collection.


> to objects they want to keep around (instead of relying on an event
> queue
> to keep your object live), making things a bit more explicit.  On the
> other

If you are wondering about the dreadful waste of resources that would
occur if there are many objects waiting for messages, that would not
happen.  There is no busy waiting.  Stale objects are moved to disk,
probably a remote location for long term storage.  If those objects are
not referred to by any others then they will be garbage collected.  It
is valid to have an object that exists, but does not receive a
messages.  At any time, some unknown application can find out the object
exists and start sending messages to it..



> hand, you still have the issue of needing parallel broadcast paths for
> different
> contexts of information on the same subject.  For instance, if you have
> two windows open at once, in the same instance of the application, how
> do
> you prevent destructive cross-chatter?

If you have two windows then you have two objects; communication to each
does not create the cross-chatter.  If you plan to control those windows
through a single application object then the programmer will have to
make sure they mention what window to update when speaking to the
application.  This latter design is probably bad.  The programmer should
have the application pass the window object to the speaker.  That way
the speaker can do direct communication.




-- 
----------------------------------------------------------------------
Kyle Lahnakoski                                  Arcavia Software Ltd.
(416) 892-7784                                 http://www.arcavia.com