VASmalltalk on Multi Core Processors

[Joost Bossuyt]

We noticed that VASmalltalk always uses a single CPU thread on dual-cpu, hyperthreading or dual-core machines. How can we remedy that?

Another problem is that EMSRV only runs on single CPU thread architectures. Are there any plans to change this in the future?
Or are there plans to switch to another versioning control system?

Thanks,
Joost.

[marten]

We noticed that VASmalltalk always uses a single CPU thread on dual-cpu, hyperthreading or dual-core machines. How can we remedy that?

You can not change this ... another thread can only be used for TCP/IP calls or other external call ... the virtual machine itself is single thread based and I do not think, that this might change in the near future ;.)

Another problem is that EMSRV only runs on single CPU thread architectures. Are there any plans to change this in the future?
Or are there plans to switch to another versioning control system?

The restriction for single cpu thread architectures is only valid for Windows based system ... you can run the emsrv on dual-cpu systems without any problems.

And I hope not, that they throw ENVY out of the product - it is the best source code system I've used so far ...

Marten

[Eric Clayberg]

We noticed that VASmalltalk always uses a single CPU thread on dual-cpu, hyperthreading or dual-core machines. How can we remedy that?

You can't. Smalltalk runs on a single OS thread. Internally it has its own processor scheduler. One can create separate processes with Smalltalk, typically by sending fork: or forkAt: to a block.

ProcessorScheduler implements a round-robin with priorities scheduler. In other words, a running process will hold the CPU until one of the following occurs:

* It performs an operation that causes it to suspend
* Another process of higher priority is resumed.
* The process is ended.

At that point, the scheduling algorithm ensures that the highest priority process that is ready to run next. If there is more than one process satisfying this criterion, then the process that has been waiting longest is selected for execution.

Please see the Base Programmer's Reference manual for a complete discussion of process scheduling and how to set priorities and ways to synchronize Smalltalk processes.

VA Smalltalk does have a mechanism to call out to dll's and MQ via Asynchronous Callout. These calls do execute on a separate OS thread. However, primitives cannot be called via ACO since they are logically a part of the VM.

There is documentation in the Programmers Base Reference Guide which describes how to use the Ayschronous Callout feature.

Another problem is that EMSRV only runs on single CPU thread architectures. Are there any plans to change this in the future?

EMSRV would need to run under VMware (or Windows VirtualPC) on this hardware so that it would see only one CPU and be safe. It will run native on a DualCore box if the -mp commandline switch is specified. EMSRV is still supported by IBM (in Phoenix) and they will not take a defect for EMSRV running native on an multiprocessor box.

BTW, the warning against running on an multiprocessor box was added to EMSRV 7.1a in response to complaints from customers that their repositories were being corrupted on multi-processor machines. It is (was?) a file locking issue on some versions of Windows.

Corruptions were not frequent or reproducible on demand. IBM never isolated the problem. It may indeed be fixed by later version of Windows, but we don't know for sure.

Or are there plans to switch to another versioning control system?

Absolutely not.