managed/native thread affinity

Hi,

I have two questions about managed/native thread affinity in applications
hosted by ASP.NET, running under version 2.0 of the .NET Framework:

1) Is it ever possible for two or more managed threads to be multiplexed
onto the same native thread?

2) Is it ever possible for a managed thread to be switched from one native
thread to another during its lifetime?

Are either of these scenarios possible in future version of the ASP.NET or
the Framework?

I am asking because I have an ASP.NET application that calls into a Java
virtual machine through the Java Native Interface (JNI). JNI (actually the
JVM) can maintain state across calls, and this state is
native-thread-specific. To use JNI on a given thread, I must first call an
API method to "attach" the thread to the JVM. Here two things happen:
- The JVM creates a Java thread that is mapped to the native thread on which
the call was made.
- I get back a handle to use for making future JNI calls. This handle is
specific to the calling native thread.
Instability will result if native thread A attempts to make JNI calls using
native thread B's handle (scenario 1 above), or if two separate "logical"
threads of execution attempt to make calls using the same handle (scenario 2).

I am hoping to gain more insight into the current and future "rules" for
managed/native thread affinity in the CLR.

Thanks a lot.

Inline...

"zhangrusi" <zhangrusi (AT) discussions (DOT) microsoft.com> wrote

Hi,

I have two questions about managed/native thread affinity in applications
hosted by ASP.NET, running under version 2.0 of the .NET Framework:

1) Is it ever possible for two or more managed threads to be multiplexed
onto the same native thread?

Not unless you call SQLCLR managed functions (SQL2005 hosted

applications/stored procs/functios).

2) Is it ever possible for a managed thread to be switched from one native
thread to another during its lifetime?

Not, with the current versions of the CLR, anyway in V2 it's possible to

affinitize the thread through the native hosting API's (search MSDN for
details).

Are either of these scenarios possible in future version of the ASP.NET or
the Framework?

Only MSFT can tell.

I am asking because I have an ASP.NET application that calls into a Java
virtual machine through the Java Native Interface (JNI). JNI (actually
the
JVM) can maintain state across calls, and this state is
native-thread-specific. To use JNI on a given thread, I must first call
an
API method to "attach" the thread to the JVM. Here two things happen:
- The JVM creates a Java thread that is mapped to the native thread on
which
the call was made.
- I get back a handle to use for making future JNI calls. This handle is
specific to the calling native thread.
Instability will result if native thread A attempts to make JNI calls
using
native thread B's handle (scenario 1 above), or if two separate "logical"
threads of execution attempt to make calls using the same handle (scenario
2).

I am hoping to gain more insight into the current and future "rules" for
managed/native thread affinity in the CLR.

You should never assume such a mapping or affinity rule, some hosts (like
SQL2005) can allready map logical threads to fibers and fibers can migrate
from one native thread to another.

Willy.