Threading Question - CSharp

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]
- mvp@spam.guard.caspershouse.com

"Frankie" <A@B.COM> wrote in message
news:OnyKoVy8HHA.3940@TK2MSFTNGP05.phx.gbl...
> 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!
>

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

"Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote in
message news:21801F38-2714-4DAF-9FD4-F1CDCFCBFD80@microsoft.com...
> 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]
> - mvp@spam.guard.caspershouse.com
>
> "Frankie" <A@B.COM> wrote in message
> news:OnyKoVy8HHA.3940@TK2MSFTNGP05.phx.gbl...
>> 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!
>>
>

On Sep 10, 2:54 pm, "Chris Mullins [MVP]" <cmull...@yahoo.com> wrote:
> 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?

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]
- mvp@spam.guard.caspershouse.com


"Chris Mullins [MVP]" <cmullins@yahoo.com> wrote in message
news:uvs8uR%238HHA.4612@TK2MSFTNGP03.phx.gbl...
> 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
>
> "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote
> in message news:21801F38-2714-4DAF-9FD4-F1CDCFCBFD80@microsoft.com...
>> 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]
>> - mvp@spam.guard.caspershouse.com
>>
>> "Frankie" <A@B.COM> wrote in message
>> news:OnyKoVy8HHA.3940@TK2MSFTNGP05.phx.gbl...
>>> 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!
>>>
>>
>
>

On Sep 10, 3:06 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.caspershouse.com> wrote:
> 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.

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.

--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard.caspershouse.com

"Brian Gideon" <briangideon@yahoo.com> wrote in message
news:1189455713.313697.224310@y42g2000hsy.googlegroups.com...
> On Sep 10, 3:06 pm, "Nicholas Paldino [.NET/C# MVP]"
> <m...@spam.guard.caspershouse.com> wrote:
>> 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.
>
>

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...82a1211d3.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

"Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote in
message news:%23fN4LW%238HHA.2208@TK2MSFTNGP06.phx.gbl...
> 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]
> - mvp@spam.guard.caspershouse.com
>
>
> "Chris Mullins [MVP]" <cmullins@yahoo.com> wrote in message
> news:uvs8uR%238HHA.4612@TK2MSFTNGP03.phx.gbl...
>> 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
>>
>> "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote
>> in message news:21801F38-2714-4DAF-9FD4-F1CDCFCBFD80@microsoft.com...
>>> 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]
>>> - mvp@spam.guard.caspershouse.com
>>>
>>> "Frankie" <A@B.COM> wrote in message
>>> news:OnyKoVy8HHA.3940@TK2MSFTNGP05.phx.gbl...
>>>> 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!
>>>>
>>>
>>
>>
>
>

"Chris Mullins [MVP]" <cmullins@yahoo.com> wrote in message
news:eLs$DNA9HHA.2208@TK2MSFTNGP06.phx.gbl...
> 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...82a1211d3.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.