Yet another threading/invoking question...

[MuZZy]

Hi,

I'm currently rewriting some functionality which was using
multithredaing for retrieving datasets from database and updating a grid
control. I found that the grids (Infragistics UltraGrid, though it
doesn't matter) were updated (i.e. grid.DataSource = dsDataSet and
used for different purposes in the worker thread, so now i'm wrapping
all those calls to grid's methods thru invoking which is a pain in the
a$$ considering number of different methods UltraGrid has. So i wanted
to see if for now i could leave some of those calls as is.

So my question is: is it really-really... and i mean REALLY bad to call:

object o = mygridcontrol.Tag;

from a worker thread even if i am 100% sure this "mygridcontrol" is not
going to be used in the UI thread at the same time as i make this call?

Consider this sample:

// Somewhere in the UI (main) thread:
mygridcontrol = new UltraGrid();
Thread t = new Thread(new ThreadStarter(UpdateFuncDelegate));
.... and no code after that...


// In wroker thread - in function UpdateFunc

object o = mygridcontrol.Tag;

//////////////////////////

I know it's really bad bad bad!!! But still...

Please don't tell me i shouldn't do that, i know that.
Just tell me - if control is not used at time when its method is called
from a worker thread - is it going to lead to an error or not?
And if yes, why?


Thank you!
MuZZy

 

[Jon Skeet [C# MVP]]

I know it's really bad bad bad!!! But still...

Please don't tell me i shouldn't do that, i know that.
Just tell me - if control is not used at time when its method is called
from a worker thread - is it going to lead to an error or not?
And if yes, why?

I wouldn't like to say for sure whether it will lead to an error. I'd
have thought the fact that you know you shouldn't do it would be enough
to make you not do it, however. After all, even if it works in test,
you could easily get an issue on a customer box, by which time it's too
late to do it properly.

 

[Abubakar]

from a worker thread even if i am 100% sure this "mygridcontrol" is not

going to be used in the UI thread at the same time as i make this call?

Please don't tell me i shouldn't do that, i know that.
Just tell me - if control is not used at time when its method is called
from a worker thread - is it going to lead to an error or not?
And if yes, why?

[in my opinion]: I think its not only "your code" that you can check and
guarantee wont touch the grid while your worker thread is updating it. It
could be windows framework's code accessing your grid at a time you dont
anticipate, like painting the grid. I'm not sure that it really happens what
I said about painting grid by the framework, but I'm sure things like this
happens and thats why people have problems while they access there UI
controls from other than there owning thread cuz "some times" that code
works and "sometimes" it doesnt. But thats what happen in race conditions,
sometimes they arise and sometimes they dont. So why not follow the discrete
rules and do yourself a favor by doing the invoking work that u r doing
right now. It'll benifit you in the future. As Jon said, your code may not
work on your customer's box. Imagine what will happen than.

all those calls to grid's methods thru invoking which is a pain in the
a$$ considering number of different methods UltraGrid has. So i wanted

also you dont have to call "all" the methods of the grid in the working
thread, try changing some logic, like just call one function through invoke
and there do the rest.

Ab.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

So my question is: is it really-really... and i mean REALLY bad to call:

object o = mygridcontrol.Tag;

What is wrong with that? IF this call is made after the binding you should
get your value correctly, I do not think that Tag changes after a binding.

What you cannot do frmo a thread is the opposite:

mygridcontrol.Tag = o;


Then is when you can get problems


BTW, what does UltraGrid.Tag returns?

 

[Ignacio Machin \( .NET/ C# MVP \)]

but I'm sure things like this
happens and thats why people have problems while they access there UI
controls from other than there owning thread cuz "some times" that code
works and "sometimes" it doesnt.

Correct me if I'm wrong, but this is only a problem when you make a change
to the control, cause this change will probably provoke a visually change
and this is where the problem is, trying to access the UI from a worker
thread.
Reading a property of a control instance frmo a different thread is safe
(it will not block the UI), as long as accessing any other variable is.
Especially if you know this variable does not change of value once it's
assigned.

 

[Jon Skeet [C# MVP]]

<"Ignacio Machin \( .NET/ C# MVP \)" <ignacio.machin AT

What is wrong with that? IF this call is made after the binding you should
get your value correctly, I do not think that Tag changes after a binding.

What you cannot do frmo a thread is the opposite:

mygridcontrol.Tag = o;

Then is when you can get problems

No - strictly speaking, your not meant to even *access* properties on a
non-UI thread. In this case it would *probably* be okay, but I
certainly wouldn't want to risk it.

 

[Jon Skeet [C# MVP]]

<"Ignacio Machin \( .NET/ C# MVP \)" <ignacio.machin AT

Correct me if I'm wrong, but this is only a problem when you make a change
to the control, cause this change will probably provoke a visually change
and this is where the problem is, trying to access the UI from a worker
thread.
Reading a property of a control instance frmo a different thread is safe
(it will not block the UI), as long as accessing any other variable is.
Especially if you know this variable does not change of value once it's
assigned.

Blocking the UI isn't a problem - it's using *any* member which isn't
explicitly marked as being thread-safe which is the problem.

Without knowing the guts of how the Tag property is implemented, it's
very difficult to say for *certain* whether it's safe to access it from
another thread.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

No - strictly speaking, your not meant to even *access* properties on a
non-UI thread. In this case it would *probably* be okay, but I
certainly wouldn't want to risk it.

Do you have a concrete example of accesing a property of one of the stock
controls can create problems?

It should only matters if the accesor makes some changes in the internal
status of the object.

 

[Jon Skeet [C# MVP]]

<"Ignacio Machin \( .NET/ C# MVP \)" <ignacio.machin AT

Do you have a concrete example of accesing a property of one of the stock
controls can create problems?

Not off-hand - but the documentation for Control clearly states:

<quote>
Only the following members are thread safe: BeginInvoke, EndInvoke,
Invoke, InvokeRequired, and CreateGraphics.
</quote>

If the accessors were guaranteed to be thread-safe, I'd have expected
that to be documented too.

It should only matters if the accesor makes some changes in the internal
status of the object.

Or if the accessor uses some internal state which may be in the process
of changing while it is being accessed...

 

[Willy Denoyette [MVP]]

Everything boils down to one simple rule: "don't modify "window objects"
associated with a Window Handle (HWND) from another thread than the thread
that owns the Handle (the creator of the window class).
Or otherwise stated, "Window Handles" have thread affinity. That means that
only the creator thread should modify the associated UI element, but , and
this answers your question, other threads are allowed to read properties,
styles and other attributes in a thread safe manner.
Note however that in v2, a cross thread exception will get thrown (debug
build) even if you read properties from the non owning thread, IMO this is
too restrictive, but I know why it's been done that way.
UI objects that do not have thread affinity are, menus, icons and cursors,
here again multiple threads may access them but you need to coordinate
accesses (you may not modify a menu while another thread is displaying it).

Willy.

 

[MuZZy]

Everything boils down to one simple rule: "don't modify "window objects"
associated with a Window Handle (HWND) from another thread than the thread
that owns the Handle (the creator of the window class).
Or otherwise stated, "Window Handles" have thread affinity. That means that
only the creator thread should modify the associated UI element, but , and
this answers your question, other threads are allowed to read properties,
styles and other attributes in a thread safe manner.

Hm... how can you make sure you access a UI control's property/attribute
from a worker thread in a "thread safe" way other than using
Control.Invoke/BeginInvoke? There is no way you could know from a worker
thread that the UI control is not being modified right this moment and
calling a property's getter will not give you a wrong result.

 

[MuZZy]

I wouldn't like to say for sure whether it will lead to an error. I'd
have thought the fact that you know you shouldn't do it would be enough
to make you not do it, however. After all, even if it works in test,
you could easily get an issue on a customer box, by which time it's too
late to do it properly.

That has actually happened on a customer box, that's how i came across
this problem... It's better to do it right late than never

MuZZy

 

[MuZZy]

from a worker thread even if i am 100% sure this "mygridcontrol" is not
going to be used in the UI thread at the same time as i make this call?

Please don't tell me i shouldn't do that, i know that.
Just tell me - if control is not used at time when its method is called
from a worker thread - is it going to lead to an error or not?
And if yes, why?

[in my opinion]: I think its not only "your code" that you can check and
guarantee wont touch the grid while your worker thread is updating it. It
could be windows framework's code accessing your grid at a time you dont
anticipate, like painting the grid. I'm not sure that it really happens what
I said about painting grid by the framework, but I'm sure things like this
happens and thats why people have problems while they access there UI
controls from other than there owning thread cuz "some times" that code
works and "sometimes" it doesnt. But thats what happen in race conditions,
sometimes they arise and sometimes they dont. So why not follow the discrete
rules and do yourself a favor by doing the invoking work that u r doing
right now. It'll benifit you in the future. As Jon said, your code may not
work on your customer's box. Imagine what will happen than.

I agree. It's just that yesterday when i was looking at the whole code
and realized that i need to re-do the whole Worker thread/UI controls
interaction i got a bit overwhelmed, but now after a sleepless night it
seems like a solvable task. I have to change some logic here and there
to make number of different calls from Worker thread to UI limited and
also in some cases i will have to use synchronous invocation but overall
it now doesn't seem as scary as yesterday

 

[MuZZy]

Hi,

I'm currently rewriting some functionality which was using
multithredaing for retrieving datasets from database and updating a grid
control. I found that the grids (Infragistics UltraGrid, though it
doesn't matter) were updated (i.e. grid.DataSource = dsDataSet and
used for different purposes in the worker thread, so now i'm wrapping
all those calls to grid's methods thru invoking which is a pain in the
a$$ considering number of different methods UltraGrid has. So i wanted
to see if for now i could leave some of those calls as is.

So my question is: is it really-really... and i mean REALLY bad to call:

object o = mygridcontrol.Tag;

from a worker thread even if i am 100% sure this "mygridcontrol" is not
going to be used in the UI thread at the same time as i make this call?

Consider this sample:

// Somewhere in the UI (main) thread:
mygridcontrol = new UltraGrid();
Thread t = new Thread(new ThreadStarter(UpdateFuncDelegate));
... and no code after that...


// In wroker thread - in function UpdateFunc

object o = mygridcontrol.Tag;

//////////////////////////

I know it's really bad bad bad!!! But still...

Please don't tell me i shouldn't do that, i know that.
Just tell me - if control is not used at time when its method is called
from a worker thread - is it going to lead to an error or not?
And if yes, why?


Thank you!
MuZZy

Thank you all guys for your replies, now i have a concrete picture.

Actually one more question - is it anyhow different for UI thread if i
use sync invocation (Control.Invoke) instead of async one
(Control.BeginIinvoke). I know it will block the worker thread, but i
don't think it will be any different for UI thread, right?

And again, thanks for all you comments
MuZZy

 

[MuZZy]

Hi,




What is wrong with that? IF this call is made after the binding you should
get your value correctly, I do not think that Tag changes after a binding.

What you cannot do frmo a thread is the opposite:

mygridcontrol.Tag = o;


Then is when you can get problems


BTW, what does UltraGrid.Tag returns?

It's Control.Tag

 

[Willy Denoyette [MVP]]

Hm... how can you make sure you access a UI control's property/attribute
from a worker thread in a "thread safe" way other than using
Control.Invoke/BeginInvoke? There is no way you could know from a worker
thread that the UI control is not being modified right this moment and
calling a property's getter will not give you a wrong result.

Note I should have been more explicit, what I meant was:
"other threads are allowed to read 'Window properties',
'Window styles' and other attributes in a thread safe manner." Note the
"Window" ...
This is true from the Window Manager's point of view (a native component in
user32.dll).
Let me explain with a sample.
Suppose you have a form with 'Label' control and you want to get it's "Text"
property. The way this is done is by calling user32 "GetWindowText" API.
This API takes the HWND of the Label control a pointer to a buffer that will
hold the test of the label after success return and the length of the
buffer. The function sends a WM_GETTEXT window message to the owning thread
message queue (the Handle<->thread relation is maintained by the window
manager - thread affinity remember!), where it will be handled by the
WndProc. That means that an 'update' of the label can never "interfere" with
a 'read' of the text (a string), so it's thread safe right? !!Note that this
doesn't apply to simultaneous updates!!
Now, back to Windows.Forms. You know that WF sits in top of Win32 or in top
of user32's provided window services. So what WF does to read a Text
property from a Label is exactly what I described above, but it does more.
It can cache (some) properties in an internal cache to speed up fetches.
Accesses to the internal cache are not synchronized by the framework (it
would defeat the purpose of the caching), that means it's not 'thread safe'
to access them from multiple threads, this is not such a problem other than
you may read old or inconsistent data from a control, but it will never
cause deadlocks as is the case with multiple updates of UI control elements.
However, as I said before, v2 of the framework will throw an exception if
you read a property from a non-owning thread (see my previous reply).

Willy.

 

[MuZZy]

Note I should have been more explicit, what I meant was:
"other threads are allowed to read 'Window properties',
'Window styles' and other attributes in a thread safe manner." Note the
"Window" ...
This is true from the Window Manager's point of view (a native component in
user32.dll).
Let me explain with a sample.
Suppose you have a form with 'Label' control and you want to get it's "Text"
property. The way this is done is by calling user32 "GetWindowText" API.
This API takes the HWND of the Label control a pointer to a buffer that will
hold the test of the label after success return and the length of the
buffer. The function sends a WM_GETTEXT window message to the owning thread
message queue (the Handle<->thread relation is maintained by the window
manager - thread affinity remember!), where it will be handled by the
WndProc.

What you describe here for Win32 processes is exactly what happens when
i call .NET's Control.Invoke/BeginInvoke - it sends a message via
blocking PostMessage or non-blocking SendMessage.

So you are talking about getting properties/attributes using
Control.Invoke, not obtaining them directly, eg

bool bVisible = button.Invoke(CheckVisibleDelegate);

.... instead of

bool bVisible = button.Visible;

Right?
Only in this case you can guarantee that you request doesn't get any
inconsistent data

 

[Willy Denoyette [MVP]]

What you describe here for Win32 processes is exactly what happens when i
call .NET's Control.Invoke/BeginInvoke - it sends a message via blocking
PostMessage or non-blocking SendMessage.

So you are talking about getting properties/attributes using
Control.Invoke, not obtaining them directly, eg

bool bVisible = button.Invoke(CheckVisibleDelegate);

... instead of

bool bVisible = button.Visible;

Right?

Well, almost, what Invoke/BeginInvoke does is using SendMessage or
PostMessage to pass a "private user message" to the windows message queue
and it puts a delegate in a private queue that will get fetched by the
WndProc when it processes the "private user message". The WndProc will call
the delegate target on it's own (correct) thread. What I described above
skips the first SendMesage and uses a single SendMessage to send WM_XXX
messages to retrieve the property. That means it is inherently faster.
Note again that this is no longer possible in V2 of the framework, but it's
how it can safely be done using the Win32 API's (and the native frameworks
like MFC, WFC and ATL).

Only in this case you can guarantee that you request doesn't get any
inconsistent data

Correct. But see above.

Willy.

 

[MuZZy]

Well, almost, what Invoke/BeginInvoke does is using SendMessage or
PostMessage to pass a "private user message" to the windows message queue
and it puts a delegate in a private queue that will get fetched by the
WndProc when it processes the "private user message". The WndProc will call
the delegate target on it's own (correct) thread. What I described above
skips the first SendMesage and uses a single SendMessage to send WM_XXX
messages to retrieve the property. That means it is inherently faster.
Note again that this is no longer possible in V2 of the framework, but it's
how it can safely be done using the Win32 API's (and the native frameworks
like MFC, WFC and ATL).

Wow, wow hold on! What is "no longer possible in V2 of the framework" -
using Control.Invoke? Then i'll go hang on the tree, because i just
spent 10 hours in a row wrapping calls to controls using BeginInvoke.

Or did i miss something?

 

[Stefan Simek]

I just want to add to it, that you can check the .NET code of the stock
controls using reflector, but all that you'll get out of it is the fact
that many methods/properties end up as WinAPI calls. From there, it's
absolutely hopeless to try and analyse what will happen when you call
these from different threads. I remember having terrible problems in my
MFC days with GetWindowText and the likes, until I have learned that you
have to marshall calls to the UI thread to this (which was lots of fun
back then).

Just my 2c.
Stefan