Re: Native thread support

It's a downward spiral - with 8 Core chips becoming normal, and servers wit=
h 96 and upward, the appeal of a single-threaded language declines every ye=
ar, so the chance of someone investing in it decreases, so the appeal decre=
ases....

Such is life.

Smalltalk MT appears to have had multi-threading but the modifications need=
ed changed debugging radically (I read), and the system is Windows-only.

There was also the Roar VM for Squeak, which was multi-core (https://github=
.com/smarr/RoarVM#roarvm---the-manycore-squeakvm) but it's now 9 years sinc=
e it was updated. Still might be worth a look.

It is frustrating as the Smalltalk model of programming would seem at first=
 look to be ideal for multi-threading: individual computing objects each pi=
ning messages to each other and then responding, like a cloud of VMs where =
each little VM is one instance of a class. The usual response to questions =
about multi-threading involve running multiple Smalltalks and letting them =
communicate via the OS in some way, which is almost exactly this model. Whi=
ch begs the question: if the VMs can talk to each other using the OS, why c=
an't they talk to eachother directly in Smalltalk?

If I ever win the lottery, we will get answers to these questions and many =
more :D

Thomas

Andreas Rosenberg <[email protected]> writes:

> Greetings,
>
> just a few thoughts regarding multi-threading support. In my job, I'm
> maintaining the
> VM source code of the Digitalk Smalltalk VM. I have made some
> considerations how
> Smalltalk could support native multi-threading and there are a lot of
> hurdles to overcome:
>
> - the garbage collector: also a multi-threaded garbage collector is
> required, which is quite
> =C2=A0 complex. Each thread needs at least it's own "short term object
> heap". Even in Java a full GC
> =C2=A0 requires a "world stop" and each thread must have reached a so cal=
led
> "safe point" to make
> =C2=A0a full GC work. This requires special means of synchronization for
> each thread.
>
> - the language needs new keywords to deal with synchronization issues.
>
> - many base classes must be rewritten to be thread safe
>
> - probably a lot of other problems may exist, that are not visible in
> the first place
>
> To my knowledge currently no Smalltalk implementation exists, which can
> do multi-threading.
> The basic design was done in the 70ties and early 80ties and
> multi-threading has not
> been considered during that era.
>
> Afaik only Java and C# have a VM that supports automatic garbage
> collection with multiple native
> threads. I don't know about C#, but the team working on JDK is about 580
> people (at least
> this is number of different committers on the github project).
> Imho a considerable effort is needed, which would only be done, if there
> is a "strong need"
> and a team of clever people who might achieve this.
>
> Smalltalk is only a niche system and the user base is declining more and
> more,
> so I hardly see any reason, why anybody would invest in such a project.
>
> Best regards,
>
> Andreas
>
> On 05.02.2022 21:09, Blake McBride wrote:
>> Greetings,
>>
>> One of the things that have kept me from all Smalltalks is the lack of
>> true/native multi-threading support that is able to utilize multiple CPU=
s.
>> In today's world, it is a show-stopper for me and many others.
>>
>> I believe that GST only supports cooperative threads utilizing a single
>> machine thread.  Adding true native thread support would make GST quite
>> appealing to a large crowd IMO.  I'd also guess that adding said support
>> would be difficult but easier in GST than other Smalltalks.
>>
>> Just a thought.
>>
>> Thanks!
>>
>> Blake McBride