Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Windows Forms / WinForm General / December 2004

Tip: Looking for answers? Try searching our database.

thread safety

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Gravy - 01 Dec 2004 01:03 GMT
Can anyone suggest a good (cheap) tool that will detect when a worker thread
calls directly in to a control on the UI thread?

Thanks for your help

Graham
Ajay Kalra - 01 Dec 2004 03:23 GMT
Try the following. I have not used it but I only read about it earlier
today. The idea sounds good:

http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=3cba6
4b4-3765-49ba-8a05-11d247195e65

--
Ajay Kalra [MVP - VC++]
ajaykalra@yahoo.com

> Can anyone suggest a good (cheap) tool that will detect when a worker thread
> calls directly in to a control on the UI thread?
>
> Thanks for your help
>
> Graham
Gravy - 01 Dec 2004 08:09 GMT
Thanks Ajay,

I truely did not think there was anything that could help me. This tool does
raise a few questions for me though...

I have tried to separate my UI layer such that I have UI classes (typically
UserControls) and I have Controller classes that provide data to the UI
classes from web services. All web service calls that a controller makes is
asynchronous and I give it a callback to use to notify me of completion.
This means on completion of the web service call I'm giving data to the UI
class inside my callback and hence from a worker thread.

Because this is a common occurance for my application I tried to make my UI
classes thread aware. I did this by adding a call to InvokeRequired() and
(if necessary) Invoke() at the top of all myl public methods, this means
that I can call into me UI class from any thread and it would look after its
own marshelling. However, there was a problem here. All public UserControl
methods does not have the same sort of build in protection, so...

One big question I have is; why don't the Windows forms controls do this for
us? Does it really hurt performance? Isn't it as simple as say:

public bool Focus()
{
   if(InvokeRequired)
       Invoke(new MethodInvoker(Focus));
   else
   {
       // usual code here
   }
}

Any insite would be really great.

Thanks

Graham

> Try the following. I have not used it but I only read about it earlier
> today. The idea sounds good:
[quoted text clipped - 13 lines]
>>
>> Graham
Ajay Kalra - 01 Dec 2004 19:17 GMT
I fully agree with your assessment about using InvokeRequired in the
control itself to make the control threadsafe. I personally fail to
understand why this is not so to beginwith in Microsoft controls which
are essentially nothing more than wrappers for controls in
Comctl32.dll.

I first saw this in Chris Sells's book on WinForms and have used it
since then. This makes life easy for the clients as they dont have to
worry about providing delegates each time they call controls from the
worker thread. In addition, keeping the thread logic within a control
makes it easy to remove/add worker thread.

--------
Ajay Kalra
ajaykalra@yahoo.com

> Thanks Ajay,
>
[quoted text clipped - 51 lines]
> >>
> >> Graham
Gravy - 01 Dec 2004 20:43 GMT
Agreed Ajay, but the only problem I have found in doing this is any public
methods on the base class to my user control are not thread safe and unless
I provide new implementations of them (for example Focus(), Enabled, Visable
etc) the client experience is inconsistant. This was one reason I asked the
newsgroup earlier if anyone knows of a wrapper class sfor Form, Control and
or UserControl. I don't think anyone has done this though.

Graham

>I fully agree with your assessment about using InvokeRequired in the
> control itself to make the control threadsafe. I personally fail to
[quoted text clipped - 75 lines]
>> >>
>> >> Graham
Dmitriy Zaslavskiy - 02 Dec 2004 03:29 GMT
Few points:
1. Its really slow (switching thread and creating expensive objects such as
mutex)
2. If you want to do a bunch of updates you would want to switch manually
3. This one is probably the biggest: Invoke implies synchronization which
can lead to deadlocks.
4. Because of 3 you might want to do BeginInvoke but it changes things a
lot.
Therefore regardless of choice made by Control designers someone would not
be happy.
5. True that most controls (but not all) are wrappers of user32 and comctl32
controls but those are also not thread safe.
The truth is user32 in general is not very thread safe. There are APIs which
have thread affinity for example DestroyWindow

Gravy why does this tool raise any questions you didn't have before?
I wrote the tool but it's not really production quality so if you have
questions let me know.

>I fully agree with your assessment about using InvokeRequired in the
> control itself to make the control threadsafe. I personally fail to
[quoted text clipped - 75 lines]
>> >>
>> >> Graham
Gravy - 03 Dec 2004 01:37 GMT
Dmitriy,

the thing that got me thinking about all this thread safe control stuff
again was highlighted by GThreadCop. I was getting a lot of vialotion in one
particular method. To cut a long storey short the violations were happening
because my controller class (non UI) was dealing with interfaces that the UI
forms / controls implement. Now, in order for my controller to switch to the
UI thread I had to add a property on my interface with returned the
underlying control, but in order to get the underlying control I had to call
in to a UI control from a worker thread (the controller). Anyway after using
the GThreadCop a bit more I see that I can ignore this violation anyway.

BTW, thanks for the points below. I thought there had to be some reason for
a windows form or control not doing this.

> Few points:
> 1. Its really slow (switching thread and creating expensive objects such
[quoted text clipped - 95 lines]
>>> >>
>>> >> Graham
Dmitriy Zaslavskiy - 03 Dec 2004 03:14 GMT
Check out the comments on
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=3cba64b4-
3765-49ba-8a05-11d247195e65

on how to tell GThreadCop to ignore known OK functions

> Dmitriy,
>
[quoted text clipped - 115 lines]
>>>> >>
>>>> >> Graham

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.