Multi processors and the CLR

[JohnFol]

I know Windows / SQL etc can utilise multiple processors. In the good old
days of coding, you simply wrote the .EXE and Windows would run it on a
single processor (or a given processor for multi-processor machines)

I know also that threads exist, but am having a few problems understanding
how they are split across processors so here is an easy example.

I have a VB.Net written application that is processor intensive. It has not
been coded in any particular way to support multiple processors, or to
create multi threads.

When I run it on a dual processor machine (running 2003 server Ent Edition),
is the CLR able to spread the code execution across more than 1 processor?
Or does it just pick on a single processor and stick with it for the life of
the .Exe?


Any help most welcome.

[Niroo TP]

RE: Multi processors and the CLR

John,
the CLR cannot magically figure out which functions in your code can be
safely executed on seperate threads so everything will execute on the main
thread or at least give the impression that it is.

The runtime makes it fairly easy to create new threads using
System.Threadin g.Thread and the ThreadPool class and provides all the
necessary synchronistion primitives.

For a more "magical" way in which this might all work, you can take a look
at a research project call Polyphonic C#

http://research.microsoft.com/~nick/polyphony/

which has explicit concurrency directives in the language.

Regards
Niroo TP [MSFT]

Regards
Niroo

"JohnFol" wrote:
[color=blue]
> I know Windows / SQL etc can utilise multiple processors. In the good old
> days of coding, you simply wrote the .EXE and Windows would run it on a
> single processor (or a given processor for multi-processor machines)
>
> I know also that threads exist, but am having a few problems understanding
> how they are split across processors so here is an easy example.
>
> I have a VB.Net written application that is processor intensive. It has not
> been coded in any particular way to support multiple processors, or to
> create multi threads.
>
> When I run it on a dual processor machine (running 2003 server Ent Edition),
> is the CLR able to spread the code execution across more than 1 processor?
> Or does it just pick on a single processor and stick with it for the life of
> the .Exe?
>
>
> Any help most welcome.
>
>
>[/color]

[JohnFol]

Re: Multi processors and the CLR

Niroo, many thanks for the clarification.


"Niroo TP" <NirooTP@discus sions.microsoft .com> wrote in message
news:C2240C59-E32C-42D4-8D52-93355144876E@mi crosoft.com...[color=blue]
> John,
> the CLR cannot magically figure out which functions in your code can be
> safely executed on seperate threads so everything will execute on the main
> thread or at least give the impression that it is.
>
> The runtime makes it fairly easy to create new threads using
> System.Threadin g.Thread and the ThreadPool class and provides all the
> necessary synchronistion primitives.
>
> For a more "magical" way in which this might all work, you can take a look
> at a research project call Polyphonic C#
> http://research.microsoft.com/~nick/polyphony/
> which has explicit concurrency directives in the language.
>
> Regards
> Niroo TP [MSFT]
>
> Regards
> Niroo
>
> "JohnFol" wrote:
>[color=green]
>> I know Windows / SQL etc can utilise multiple processors. In the good old
>> days of coding, you simply wrote the .EXE and Windows would run it on a
>> single processor (or a given processor for multi-processor machines)
>>
>> I know also that threads exist, but am having a few problems
>> understanding
>> how they are split across processors so here is an easy example.
>>
>> I have a VB.Net written application that is processor intensive. It has
>> not
>> been coded in any particular way to support multiple processors, or to
>> create multi threads.
>>
>> When I run it on a dual processor machine (running 2003 server Ent
>> Edition),
>> is the CLR able to spread the code execution across more than 1
>> processor?
>> Or does it just pick on a single processor and stick with it for the life
>> of
>> the .Exe?
>>
>>
>> Any help most welcome.
>>
>>
>>[/color][/color]