Threading Question

[Frankie]

Just getting my feet wet with threading...

Is it the case that... once a method starts executing in a given thread,
that method will [can only] finish executing on that same thread? Or is it
possible for a given method to begin executing on a thread, and then finish
executing on another thread. I would think the former is true and the latter
false. Correct?

Thanks!

 

[Nicholas Paldino [.NET/C# MVP]]

Frankie,

You are correct. Once you execute a method on a thread, it is that
thread which will process the method, until the method completes.

 

[Chris Mullins [MVP]]

Well, Truth be told, I always wonder about this. For the Original Poster -
don't worry, you're fine -- we're way in the real of useless arcana at this
point...

It's the "Logical Thread vs Physical Thread" debate that goes on with the
CLR.

I'll agree that the method will always run on the same logical thread, but I
could see the logical thread having a different physical thread swapped out.

If you were doing strange threading things that had alot of affinity (TLS,
etc) I could see this cropping up sometime in the future.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

Frankie,

You are correct. Once you execute a method on a thread, it is that
thread which will process the method, until the method completes.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Just getting my feet wet with threading...

Is it the case that... once a method starts executing in a given thread,
that method will [can only] finish executing on that same thread? Or is
it possible for a given method to begin executing on a thread, and then
finish executing on another thread. I would think the former is true and
the latter false. Correct?

Thanks!

 

[Brian Gideon]

Well, Truth be told, I always wonder about this. For the Original Poster -
don't worry, you're fine -- we're way in the real of useless arcana at this
point...

It's the "Logical Thread vs Physical Thread" debate that goes on with the
CLR.

I'll agree that the method will always run on the same logical thread, but I
could see the logical thread having a different physical thread swapped out.

If you were doing strange threading things that had alot of affinity (TLS,
etc) I could see this cropping up sometime in the future.

--

I suspect you're right. That is the whole premise behind
Thread.BeginThreadAffinity is it not?

 

[Nicholas Paldino [.NET/C# MVP]]

If done correctly, there shouldn't be a problem. You are right that you
might not always have physical thread affinity (SQL Server is an example of
this), but that's not something that you should be worried about while
programming with the CLR (at least since .NET 2.0, when the distinction
between logical thread and physical thread was firmly established).

Assuming that the host is correctly programmed, things such as TLS and
whatnot should work accordingly.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Well, Truth be told, I always wonder about this. For the Original Poster -
don't worry, you're fine -- we're way in the real of useless arcana at
this point...

It's the "Logical Thread vs Physical Thread" debate that goes on with the
CLR.

I'll agree that the method will always run on the same logical thread, but
I could see the logical thread having a different physical thread swapped
out.

If you were doing strange threading things that had alot of affinity (TLS,
etc) I could see this cropping up sometime in the future.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

Frankie,

You are correct. Once you execute a method on a thread, it is that
thread which will process the method, until the method completes.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Just getting my feet wet with threading...

Is it the case that... once a method starts executing in a given thread,
that method will [can only] finish executing on that same thread? Or is
it possible for a given method to begin executing on a thread, and then
finish executing on another thread. I would think the former is true and
the latter false. Correct?

Thanks!

 

[Brian Gideon]

Assuming that the host is correctly programmed, things such as TLS and
whatnot should work accordingly.

I don't think the same can be said of unmanaged APIs that require
thread affinity though. Fortunately, I don't there are very many of
those out there.

 

[Nicholas Paldino [.NET/C# MVP]]

Brian,

Absolutely, but if you are using unmanaged APIs, it's already well-known
that you are forfeiting the benefits of the CLR for the duration of that
call.

 

[Chris Mullins [MVP]]

That whole "if done correctly" though, is quite a can of worms.

For example, I do alot of LDAP & AD, through System.DirectoryServices. These
classes appear (through emperical evidence) to have native thread affinity.
I don't see how I could use UnManaged API calls, many of which do have
thread Affinity, if I'm unsure of the physical thread that I'm on. For
certain, as long as stay "Inside the VM", the CLR will protect me. For
things like TLS, this is guaranteed (I even checked with Duffy about this,
some time ago).

.... but the sad reality is that .Net code ends up calling into native code,
and an awful lot of native code has physical thread affinity. This is often
true cases where it would not be at all obvious (c.f.,
System.DirectoryServices). The day logical and physical threads start
actually being seperate, I think alot of unexpected things are going to
break.

I've heard a number of people say SQL Server does this already, but I don't
think it's the case. For sure, there was a huge effort in .Net 2.0 to get
Fibers working right for the SQL Guys, but (again, according to Duffy) this
was abandoned at the 9th hour, and offically, "Not Supported"
(http://www.bluebytesoftware.com/blog/PermaLink,guid,2d0038b5-7ba5-421f-860b-d9282a1211d3.aspx).

Is there any evidence that SQL Server does actually swap logical threads
across physical threads?

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

If done correctly, there shouldn't be a problem. You are right that
you might not always have physical thread affinity (SQL Server is an
example of this), but that's not something that you should be worried
about while programming with the CLR (at least since .NET 2.0, when the
distinction between logical thread and physical thread was firmly
established).

Assuming that the host is correctly programmed, things such as TLS and
whatnot should work accordingly.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Well, Truth be told, I always wonder about this. For the Original
Poster - don't worry, you're fine -- we're way in the real of useless
arcana at this point...

It's the "Logical Thread vs Physical Thread" debate that goes on with the
CLR.

I'll agree that the method will always run on the same logical thread,
but I could see the logical thread having a different physical thread
swapped out.

If you were doing strange threading things that had alot of affinity
(TLS, etc) I could see this cropping up sometime in the future.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

Frankie,

You are correct. Once you execute a method on a thread, it is that
thread which will process the method, until the method completes.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Just getting my feet wet with threading...

Is it the case that... once a method starts executing in a given
thread, that method will [can only] finish executing on that same
thread? Or is it possible for a given method to begin executing on a
thread, and then finish executing on another thread. I would think the
former is true and the latter false. Correct?

Thanks!

 

[Willy Denoyette [MVP]]

That whole "if done correctly" though, is quite a can of worms.

For example, I do alot of LDAP & AD, through System.DirectoryServices.

System.DirectoryServices are wrappers around ADSI, which is a COM based, as
such the affinity is due to the COM apartment requirements. But actually
this is taken care of by System.DirectoryServices itself, if the caller is
not running in an MTA thread, System.DirectoryServices will create his own
thread enter the MTA end keep this thread around for the life time of the
instance.
Note that the lower level managed LDAP libraries
(System.DirectoryServices.Protocols and
System.DirectoryServices.ActiveDirectory )do not have such affinity, nor do
they have any relation with the COM ADSI stuff), therefore you should prefer
to use these when you have to deal with LDAP connections.


These

classes appear (through emperical evidence) to have native thread
affinity. I don't see how I could use UnManaged API calls, many of which
do have thread Affinity, if I'm unsure of the physical thread that I'm on.
For certain, as long as stay "Inside the VM", the CLR will protect me. For
things like TLS, this is guaranteed (I even checked with Duffy about this,
some time ago).

... but the sad reality is that .Net code ends up calling into native
code, and an awful lot of native code has physical thread affinity. This
is often true cases where it would not be at all obvious (c.f.,
System.DirectoryServices). The day logical and physical threads start
actually being seperate, I think alot of unexpected things are going to
break.

I've heard a number of people say SQL Server does this already, but I
don't think it's the case. For sure, there was a huge effort in .Net 2.0
to get Fibers working right for the SQL Guys, but (again, according to
Duffy) this was abandoned at the 9th hour, and offically, "Not Supported"
(http://www.bluebytesoftware.com/blog/PermaLink,guid,2d0038b5-7ba5-421f-860b-d9282a1211d3.aspx).

Is there any evidence that SQL Server does actually swap logical threads
across physical threads?

Sure it does, the SQL server host manages his own threading and fibers
stuff, he doesn't use the CLR threads (nor it's ThreadPool).
The SQL team is the only team that knows what fibers are all about, after a
failed attempt to integrate this in the CLR, they decided to handle
threading themselves and gave up about the CLR for this. IMO we won't ever
see fibers supported in the CLR.
There are a couple of other CLR services that aren't used by SQLCLR, these
guys are hunting for 99.9999% availability, something that can't be
guaranteed by the CLR.

Willy.