Hi,

You might learn something from the class/hierarchy ProcessSpecificVariable, esp. the methods in the category 'process specific' in the Process class, e.g. #psValueAt:[put:]

Sven

How do you modify a variable in another process?
DON'T.
Yes, it is possible.
No, it's an amazingly bad idea in any programming language.

First, let us see a simple, obvious, and portable way to do
what you want.  (It has one minor problem which I'll get to.)

shared := Array new: 1.
shared at: 1 put: initialValue.
[ 1 to: 100 do: [:i |
Transcript show: (shared at: 1); cr
] fork.

The 'shared' object is a secret shared between the new Process and the
(method in the) Process that created it.  Nothing else can see it, let
alone change it.  This is a good thing.

The minor problem I mentioned?
It might not work.  If the two Processes are running on different
cores, and if the compiler is (too) smart (enough), memory writes
from one Process might not be noticed by memory reads at the other.

You should think about processes the way you think about objects.
"How do I change a variable in another object?  DON'T!"
"How do I change a variable in another process? DON'T!"
What variables another object has or another process has are
PRIVATE IMPLEMENTATION DETAILS.
The Object-Oriented rule is

ASK, DON'T TELL.

That is, you should never force an object or process to do
anything, you should ASK it to do something by sending a
message.

The way you send a message to a Process is via a SharedQueue.

shared := SharedQueue new.
[ |text next|
text := 'Kalimera Kosmou'.
1 to: 100 do: [:i |
next := shared nextOrNil.
next ifNotNil: [text := next].
Transcript show: text; cr]
] fork.
shared nextPut: 'Pozdrav svijete'.
shared nextPut: 'Hello world'.

With this approach, the receiving process has complete
and absolute control over when the variable ('text') is
changed and indeed whether it is changed.

There are several other tools you can use, but my experience
has been that getting things right using Processes and
SharedQueues FIRST before trying other kinds of things
(like rolling your own Mailbox or Rendezvous classes) makes
concurrent programming so much easier.

It also drives home that the originating process does not
know when or whether the receiving process has acted on
the message, but that's the case with shared variables too,
modern hardware and operating systems being what they are.
It's just more OBVIOUS this way and more CONTROLLED.

On Tue, 2 Mar 2021 at 22:42, mspgate@gmail.com wrote:

Why do the parameters for the sequencer have to be
process variables?  Why can't they be instance
variables of an object?

SequenceControl (mutex v1 v2 ...)
initialize
mutex := Mutex new.
v1 := default for v1.
v2 := default for v2.
...
v1
^v1
v1: x
validate x all by itself
mutex critical: [
validate x in context of other variables
v1 := x].

This takes care of all the memory fiddling necessary.
Once again, the existence of this object would be a shared
secret between the process and the creating process.

On Wed, 3 Mar 2021 at 00:48, mspgate@gmail.com wrote:

Open a Playground in Pharo.
Enter the following text.

(((ProcessorScheduler selectors)
select:  [:each | each endsWith: 'Priority'])
collect: [:each | {Processor perform: each. each}])
sorted:  [:x :y | x first <= y first]

Select it, the ctrl-i or "Inspect It" from a menu).
That gives you a list of the named priorities.

From that you will be able to answer your own question.

On Fri, 26 Mar 2021 at 06:39, mspgate@gmail.com wrote:

Code fragments are by definition incomplete.
SharedQueue with a "d".

On Sun, 28 Mar 2021 at 03:38, mspgate@gmail.com wrote: