[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Native thread support

From: Thomas Worthington
Subject: Re: Native thread support
Date: Mon, 14 Feb 2022 20:31:11 +0000
User-agent: mu4e 1.7.5; emacs 27.2

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 
( 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 


Andreas Rosenberg <> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]