Re: Native thread support

[Thomas Worthington]

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

Such is life.

Smalltalk MT appears to have had multi-threading but the modifications needed 
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 since 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 pining 
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. Which 
begs the question: if the VMs can talk to each other using the OS, why can'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 <andreas_rosenberg@web.de> 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
>   complex. Each thread needs at least it's own "short term object
> heap". Even in Java a full GC
>   requires a "world stop" and each thread must have reached a so called
> "safe point" to make
>  a 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 CPUs.
>> 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