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]

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:

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.

[JohnFol]

Niroo, many thanks for the clarification.
"Niroo TP" <Ni*****@discus sions.microsoft .com> wrote in message
news:C2******** *************** ***********@mic rosoft.com...

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:

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.