Threading changes in .NET 2

[Chris S.]

Can anyone explain if there are any changes or improvements to the
threading system in .NET 2? I haven't found any in the "What's new"
webpage but have heard some improvements and changes have been made
(but nothing more specific than that)

[jeremiah johnson]

Chris S. wrote:

Can anyone explain if there are any changes or improvements to the
threading system in .NET 2? I haven't found any in the "What's new"
webpage but have heard some improvements and changes have been made
(but nothing more specific than that)

the only thing that comes to mind immediately is that you can set the
minimum and maximum number of threads in the default threadpool. so
rather than the max threads available being 25x(processor cores in the
system) you can set the max to, for example, 4.

this probably extends to any threadpool you create as well.

its early in my neck of the woods. that's all i can think of right now.

[Kevin Spencer]

A related enhancement is the introduction of the BackgroundWorker component
for Windows Forms. Because Windows Forms are STA, threading has always been
problematic with them. While the BackgroundWorker class is not an
enhancement of the Threading model, it certainly comes in handy when one
needs to perform threaded tasks with Windows Forms.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.

"jeremiah johnson" <na*******@gmail.com> wrote in message
news:OX**************@TK2MSFTNGP09.phx.gbl...

Chris S. wrote:

Can anyone explain if there are any changes or improvements to the
threading system in .NET 2? I haven't found any in the "What's new"
webpage but have heard some improvements and changes have been made
(but nothing more specific than that)

the only thing that comes to mind immediately is that you can set the
minimum and maximum number of threads in the default threadpool. so
rather than the max threads available being 25x(processor cores in the
system) you can set the max to, for example, 4.

this probably extends to any threadpool you create as well.

its early in my neck of the woods. that's all i can think of right now.

[Chris S.]

I've read on this thread:

http://groups.google.co.uk/group/mic...52b054bb9ac568

about .NET 2.0 throwing exceptions with Control.Invoke. This is
probably the threading changes I was told about. But doesn't .NET 1.1
do this already when the thread doing the UI update hasn't got a handle
(and no InvokeRequired is used)?

[Brian Gideon]

Chris,

In addition to forms and controls not being thread-safe they also have
thread affinity requirements. They must only be accessed on the thread
that created them. Typically, that's the main UI thread. In .NET 1.0
and 1.1 you could access the control from another thread and it would
appear to work fine at least some of the time. However, the behavior
was unpredictable. I frequently observed the problems manifesting
themselves when a control would unexpectedly appear as a large red X
with a white background. In .NET 2.0 Microsoft decided to throw an
exception if a control was accessed from another thread immediately
informing the developer of a bug. That may be the exception you're
thinking of, but it isn't thrown by Control.Invoke.

Brian

Chris S. wrote:

I've read on this thread:

http://groups.google.co.uk/group/mic...52b054bb9ac568

about .NET 2.0 throwing exceptions with Control.Invoke. This is
probably the threading changes I was told about. But doesn't .NET 1.1
do this already when the thread doing the UI update hasn't got a handle
(and no InvokeRequired is used)?

[William Stacey [MVP]]

Fixed a bug in Monitor to throw AbandonedMutexException as it should.
Semaphore class added. Interlocked class adds generic stuff,
ParameterizedThreadStart delegate added to Thread class, TP updates. I am
sure there are many more.

--
William Stacey [MVP]

"Chris S." <sl********@gmail.com> wrote in message
news:11*********************@e56g2000cwe.googlegro ups.com...
| Can anyone explain if there are any changes or improvements to the
| threading system in .NET 2? I haven't found any in the "What's new"
| webpage but have heard some improvements and changes have been made
| (but nothing more specific than that)
|

[William Stacey [MVP]]

That is an interesting question. Where would they throw that error? Would
seem inside an enqueue method for the window message queue would be a good
single place. Control.Invoke/BeginInvoke must eventually call into some
enqueue logic I would think.

--
William Stacey [MVP]

"Brian Gideon" <br*********@yahoo.com> wrote in message
news:11*********************@e56g2000cwe.googlegro ups.com...
| Chris,
|
| In addition to forms and controls not being thread-safe they also have
| thread affinity requirements. They must only be accessed on the thread
| that created them. Typically, that's the main UI thread. In .NET 1.0
| and 1.1 you could access the control from another thread and it would
| appear to work fine at least some of the time. However, the behavior
| was unpredictable. I frequently observed the problems manifesting
| themselves when a control would unexpectedly appear as a large red X
| with a white background. In .NET 2.0 Microsoft decided to throw an
| exception if a control was accessed from another thread immediately
| informing the developer of a bug. That may be the exception you're
| thinking of, but it isn't thrown by Control.Invoke.
|
| Brian
|
| Chris S. wrote:
| > I've read on this thread:
| >
| >
http://groups.google.co.uk/group/mic...52b054bb9ac568
| >
| > about .NET 2.0 throwing exceptions with Control.Invoke. This is
| > probably the threading changes I was told about. But doesn't .NET 1.1
| > do this already when the thread doing the UI update hasn't got a handle
| > (and no InvokeRequired is used)?
|

[Brian Gideon]

William,

I don't have 2.0 on this computer so I can't test it right now, but I
think it's thrown in the calling thread upon invoking a property or
method. The exception was something like "illegal cross thread
operation...". I don't think Control.Invoke or the message queue play
role in this.

Brian

William Stacey [MVP] wrote:

That is an interesting question. Where would they throw that error? Would
seem inside an enqueue method for the window message queue would be a good
single place. Control.Invoke/BeginInvoke must eventually call into some
enqueue logic I would think.

--
William Stacey [MVP]

"Brian Gideon" <br*********@yahoo.com> wrote in message
news:11*********************@e56g2000cwe.googlegro ups.com...
| Chris,
|
| In addition to forms and controls not being thread-safe they also have
| thread affinity requirements. They must only be accessed on the thread
| that created them. Typically, that's the main UI thread. In .NET 1.0
| and 1.1 you could access the control from another thread and it would
| appear to work fine at least some of the time. However, the behavior
| was unpredictable. I frequently observed the problems manifesting
| themselves when a control would unexpectedly appear as a large red X
| with a white background. In .NET 2.0 Microsoft decided to throw an
| exception if a control was accessed from another thread immediately
| informing the developer of a bug. That may be the exception you're
| thinking of, but it isn't thrown by Control.Invoke.
|
| Brian
|

[Willy Denoyette [MVP]]

Note that this is only true when running in debug mode, there is no such
check done when running a release build, so you won't get the exception. The
check is done by the CLR (where it's called a Managed Debugging Assistant or
MDA) and is quite expensive as it has to compare the thread ID of the thread
that accesses a window handle to the thread ID of the creator (the UI
thread) of the handle, that's why it's only done when debugging or when you
explicitly enable the MDA. Search the docs for MDA if you want to enable
this (or other MDA's) for release builds as well.
Willy.
"Brian Gideon" <br*********@yahoo.com> wrote in message
news:11*********************@e56g2000cwe.googlegro ups.com...
| Chris,
|
| In addition to forms and controls not being thread-safe they also have
| thread affinity requirements. They must only be accessed on the thread
| that created them. Typically, that's the main UI thread. In .NET 1.0
| and 1.1 you could access the control from another thread and it would
| appear to work fine at least some of the time. However, the behavior
| was unpredictable. I frequently observed the problems manifesting
| themselves when a control would unexpectedly appear as a large red X
| with a white background. In .NET 2.0 Microsoft decided to throw an
| exception if a control was accessed from another thread immediately
| informing the developer of a bug. That may be the exception you're
| thinking of, but it isn't thrown by Control.Invoke.
|
| Brian
|
| Chris S. wrote:
| > I've read on this thread:
| >
| >
http://groups.google.co.uk/group/mic...52b054bb9ac568
| >
| > about .NET 2.0 throwing exceptions with Control.Invoke. This is
| > probably the threading changes I was told about. But doesn't .NET 1.1
| > do this already when the thread doing the UI update hasn't got a handle
| > (and no InvokeRequired is used)?
|

[Brian Gideon]

Willy,

I didn't realize that. That's good to know. Thanks for posting that
note.

Brian

Willy Denoyette [MVP] wrote:

Note that this is only true when running in debug mode, there is no such
check done when running a release build, so you won't get the exception. The
check is done by the CLR (where it's called a Managed Debugging Assistant or
MDA) and is quite expensive as it has to compare the thread ID of the thread
that accesses a window handle to the thread ID of the creator (the UI
thread) of the handle, that's why it's only done when debugging or when you
explicitly enable the MDA. Search the docs for MDA if you want to enable
this (or other MDA's) for release builds as well.
Willy.
"Brian Gideon" <br*********@yahoo.com> wrote in message
news:11*********************@e56g2000cwe.googlegro ups.com...
| Chris,
|
| In addition to forms and controls not being thread-safe they also have
| thread affinity requirements. They must only be accessed on the thread
| that created them. Typically, that's the main UI thread. In .NET 1.0
| and 1.1 you could access the control from another thread and it would
| appear to work fine at least some of the time. However, the behavior
| was unpredictable. I frequently observed the problems manifesting
| themselves when a control would unexpectedly appear as a large red X
| with a white background. In .NET 2.0 Microsoft decided to throw an
| exception if a control was accessed from another thread immediately
| informing the developer of a bug. That may be the exception you're
| thinking of, but it isn't thrown by Control.Invoke.
|
| Brian
|

[William Stacey [MVP]]

Thanks Willy. Which one of the MDAs does this? I looked at the list and
could not find one that seemed to match.

--
William Stacey [MVP]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:e8**************@TK2MSFTNGP12.phx.gbl...
| Note that this is only true when running in debug mode, there is no such
| check done when running a release build, so you won't get the exception.
The
| check is done by the CLR (where it's called a Managed Debugging Assistant
or
| MDA) and is quite expensive as it has to compare the thread ID of the
thread
| that accesses a window handle to the thread ID of the creator (the UI
| thread) of the handle, that's why it's only done when debugging or when
you
| explicitly enable the MDA. Search the docs for MDA if you want to enable
| this (or other MDA's) for release builds as well.
|
|
| Willy.
|
|
| "Brian Gideon" <br*********@yahoo.com> wrote in message
| news:11*********************@e56g2000cwe.googlegro ups.com...
|| Chris,
||
|| In addition to forms and controls not being thread-safe they also have
|| thread affinity requirements. They must only be accessed on the thread
|| that created them. Typically, that's the main UI thread. In .NET 1.0
|| and 1.1 you could access the control from another thread and it would
|| appear to work fine at least some of the time. However, the behavior
|| was unpredictable. I frequently observed the problems manifesting
|| themselves when a control would unexpectedly appear as a large red X
|| with a white background. In .NET 2.0 Microsoft decided to throw an
|| exception if a control was accessed from another thread immediately
|| informing the developer of a bug. That may be the exception you're
|| thinking of, but it isn't thrown by Control.Invoke.
||
|| Brian
||
|| Chris S. wrote:
|| > I've read on this thread:
|| >
|| >
|
http://groups.google.co.uk/group/mic...52b054bb9ac568
|| >
|| > about .NET 2.0 throwing exceptions with Control.Invoke. This is
|| > probably the threading changes I was told about. But doesn't .NET 1.1
|| > do this already when the thread doing the UI update hasn't got a handle
|| > (and no InvokeRequired is used)?
||
|
|

[Willy Denoyette [MVP]]

Well, it looks like this MDA was cut from the list and can no longer be
controlled from outside a managed debugger like msdb or vs debugger. That
means that this MDA is on by-default under the debugger and off otherwise,
you can no longer control this through an environment variable, registry or
config file setting.
Others that were cut (though still in the list), are PInvokeLog and
QueryInterface MDA. It looks like these (and probably some other too) have
been removed very late in the beta process, I've usefully used the
Illegalcrossthreadcall MDA in beta2. I need to spend some time on this to
find out what still available in the relase version of V2.

Willy.
"William Stacey [MVP]" <wi************@gmail.com> wrote in message
news:uD**************@TK2MSFTNGP09.phx.gbl...
| Thanks Willy. Which one of the MDAs does this? I looked at the list and
| could not find one that seemed to match.
|
| --
| William Stacey [MVP]
|
| "Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
| news:e8**************@TK2MSFTNGP12.phx.gbl...
|| Note that this is only true when running in debug mode, there is no such
|| check done when running a release build, so you won't get the exception.
| The
|| check is done by the CLR (where it's called a Managed Debugging Assistant
| or
|| MDA) and is quite expensive as it has to compare the thread ID of the
| thread
|| that accesses a window handle to the thread ID of the creator (the UI
|| thread) of the handle, that's why it's only done when debugging or when
| you
|| explicitly enable the MDA. Search the docs for MDA if you want to enable
|| this (or other MDA's) for release builds as well.
||
||
|| Willy.
||
||
|| "Brian Gideon" <br*********@yahoo.com> wrote in message
|| news:11*********************@e56g2000cwe.googlegro ups.com...
||| Chris,
|||
||| In addition to forms and controls not being thread-safe they also have
||| thread affinity requirements. They must only be accessed on the thread
||| that created them. Typically, that's the main UI thread. In .NET 1.0
||| and 1.1 you could access the control from another thread and it would
||| appear to work fine at least some of the time. However, the behavior
||| was unpredictable. I frequently observed the problems manifesting
||| themselves when a control would unexpectedly appear as a large red X
||| with a white background. In .NET 2.0 Microsoft decided to throw an
||| exception if a control was accessed from another thread immediately
||| informing the developer of a bug. That may be the exception you're
||| thinking of, but it isn't thrown by Control.Invoke.
|||
||| Brian
|||
||| Chris S. wrote:
||| > I've read on this thread:
||| >
||| >
||
|
http://groups.google.co.uk/group/mic...52b054bb9ac568
||| >
||| > about .NET 2.0 throwing exceptions with Control.Invoke. This is
||| > probably the threading changes I was told about. But doesn't .NET 1.1
||| > do this already when the thread doing the UI update hasn't got a
handle
||| > (and no InvokeRequired is used)?
|||
||
||
|
|

[Brian Gideon]

Willy,

I tested this last night and I verified that the exception does indeed
occur in debug builds, but not release builds as you already indicated.
I'll be honest. I didn't even know MDAs existed until you said
something. I can see a lot of potential uses for this. Is there any
possibility that Microsoft would open this functionality up to us. I'd
like to add my own MDAs for use in some class libraries. The wheels
are spinning in my head right now...

Brian

Willy Denoyette [MVP] wrote:

Well, it looks like this MDA was cut from the list and can no longer be
controlled from outside a managed debugger like msdb or vs debugger. That
means that this MDA is on by-default under the debugger and off otherwise,
you can no longer control this through an environment variable, registry or
config file setting.
Others that were cut (though still in the list), are PInvokeLog and
QueryInterface MDA. It looks like these (and probably some other too) have
been removed very late in the beta process, I've usefully used the
Illegalcrossthreadcall MDA in beta2. I need to spend some time on this to
find out what still available in the relase version of V2.

Willy.