Re: Performance assistance / advice

And finally, another twist on Hewitt Actors, is to have them behave transactionally. No message is sent, no become is performed, until the Actor function body exits normally. That means that the Actor body cannot see any effects of its own SENDS and BECOMES. It is as though they all happen simultaneously at successful exit, in between arriving messages.

Actor local data (in the functonal closure itself) becomes an analog of thread local storage. But this data is visible to all simultaneous callers, and so cannot be safely mutated. Any mutation should be performed functionally and made part of a BECOME. 

Locks are excluded from consideration here. They really aren’t needed except in just one place - in the envelope holding the Actors behavior closure. In a concurrent environment with functionally pure behavior against the visible local data, you need to arbitrate against simultaneous attempts to BECOME, and perform a retry of the loser if a collision occurs.

> On Mar 12, 2025, at 17:23, David McClain <[email protected]> wrote:
> 
> In a multiprocessing environment, having Actors equivalent to function calls (if that were possible), is a distinct disadvantage. Function calls don’t switch threads. Message sends allow for any available thread to pick up the message and deliver it to the Actor function. This enables fully parallel concurrent behavior. 
> 
>> On Mar 12, 2025, at 17:00, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
>> 
>> .. and so once you move the indirection up a level into a wrapper, we lose the equivalence between function calls and Actor message sends.
>> 
>> 
>> 
>>> On Mar 12, 2025, at 16:59, David McClain <[email protected]> wrote:
>>> 
>>> Yes, I am aware of Steele’s comments about Actors.
>>> 
>>> However, Hewitt’s Actors require the ability to perform a BECOME - to become a different “function” on succeeding messages. I fail to see how a simple lambda expression could do this. But a closure could do so.
>>> 
>>> But lacking any visibility into functional closures in either Lisp or Scheme, we are left with encapsulating a closure (for private data + function) into a wrapper envelope for the indirection needed to perform a BECOME.
>>> 
>>> 
>>> 
>>>> On Mar 12, 2025, at 16:52, Tim Bradshaw (as tfb at cley dot com) <[email protected]> wrote:
>>>> 
>>>> On 12 Mar 2025, at 22:16, David McClain <[email protected]> wrote:
>>>>> I believe Scheme was an outgrowth in the late 80s for the Connection Machine??
>>>> 
>>>> Almost.  There was Planner, which I don't think ever really existed, and then Conniver which I think was an implementation of something with incoherent semantics.  Then Hewitt invented Actors, and ?Steele and Sussman? wanted to implement Actors in terms of lambda calculus on top of maclisp, and at some point had the blinding realisation that actors and functions (ie lambda expressiona) which never returned but just called another function (their continuation) were the same thing.  The resulting unified language was called 'Schemer'.  But ITS had six-character filenames.
>>>> 
>>>> The connection machine thing was *Lisp which I think was built on Genera (or perhaps its predecessors).  *Lisp would be a good thing to look at for ideas for vectorisation, probably (I only ever played with the simulator and I have no idea if it would run in a modern CL).
>>>> 
>>>> --tim
>>>> 
>>>> _______________________________________________
>>>> Lisp Hug - the mailing list for LispWorks users
>>>> [email protected]
>>>> http://www.lispworks.com/support/lisp-hug.html
>>> 
>> 
>> 
>> _______________________________________________
>> Lisp Hug - the mailing list for LispWorks users
>> [email protected]
>> http://www.lispworks.com/support/lisp-hug.html
> 


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html