Thread question (doubt)

[Alvin Bruney]

I dispensed some advice and its bugging me that it may not be 100% accurate.

Worker threads should not touch main thread objects. Everybody knows that
but if you pass a reference to a form object to a worker thread and you
touch that form on the worker thread. All is well.

Is that right? Will all really be well? It's a reference to the form object.
The worker thread is still modifying the main threads object, reference or
not, without using control invoke - that is, it isn't getting modified from
the thread owning the object in the correct way.

I'm not sure I now agree that this is safe. Infact I now realize that this
is absolutely wrong.
Any help here?

 

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

Alvin,


It is wrong. For a form object, even if access to the object was
synchronized (which it is not), the windows handle and all operations on it
(which the form encapsulates) requires that you make the call on the thread
where the element was created.

If you never run into problems in your scenario, then that's great, but
if you do, it's something that you could have avoided now by using a call to
Invoke.

Hope this helps.

 

[100]

Hi Alvin,

You can access and modify objects created in other threads as long as you
make sure that this is thread safe. What is thread safe in some degree
depends on your very application. Some times it means that multiple threads
can read, but only one can write when nobody is reading . In other cases
only one thread can read and so on.
But only the UI thread created the UI control can use methods and properties
that cause sending messages to its underlaying win control. This is Windows
OS issue. If someone ports WindowsForms for other platform it maight be not
required. I'm even not sure if it is necessary for CF.
However, because it is not so obvious which methods and properties send
messages usually the advice is *don't modify a control form thread different
from the one owning the undelaying window handle.

B\rgds
100

 

[Alvin Bruney]

Right, I get that.
Now, does the same thing apply for session objects - which is where I was
headed in the first place? Is the instance of the HttpContext object owned
by the main thread? The line gets a little blury here for me. If the access
is done within the context of the global object, it is guaranteed to be
called correctly. (I also need confirmation on that, but I believe this is
the case).

But what if you just spawn a worker thread and want to touch session object.
How would I use a control invoke? Control.Invoke(pass in what here though?)
the param accepts a method of type delegate not an object.

Memory failed me, I was actually making the call in global and not on a
worker thread, but this got my curiosity up.

If you never run into problems in your scenario, then that's great

it would only be a matter of time before that would start failing, like
right after the product shipped usually.

regards

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits

Alvin,


It is wrong. For a form object, even if access to the object was
synchronized (which it is not), the windows handle and all operations on it
(which the form encapsulates) requires that you make the call on the thread
where the element was created.

If you never run into problems in your scenario, then that's great, but
if you do, it's something that you could have avoided now by using a call to
Invoke.

Hope this helps.

 

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

Alvin,

Controls in ASP.NET do not follow the windows model, so you can modify
them on any thread you like (from what I know). However, you can not access
the HttpContext in other threads, as I believe that they are associated with
the threads that the page is processed on. If you want to access this
information from another thread, then I recommend you pass the HttpContext
along to that thread.

Hope this helps.


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

Right, I get that.
Now, does the same thing apply for session objects - which is where I was
headed in the first place? Is the instance of the HttpContext object owned
by the main thread? The line gets a little blury here for me. If the access
is done within the context of the global object, it is guaranteed to be
called correctly. (I also need confirmation on that, but I believe this is
the case).

But what if you just spawn a worker thread and want to touch session object.
How would I use a control invoke? Control.Invoke(pass in what here though?)
the param accepts a method of type delegate not an object.

Memory failed me, I was actually making the call in global and not on a
worker thread, but this got my curiosity up.

If you never run into problems in your scenario, then that's great

it would only be a matter of time before that would start failing, like
right after the product shipped usually.

regards

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
message news:[email protected]...

Alvin,


It is wrong. For a form object, even if access to the object was
synchronized (which it is not), the windows handle and all operations on it
(which the form encapsulates) requires that you make the call on the thread
where the element was created.

If you never run into problems in your scenario, then that's great, but
if you do, it's something that you could have avoided now by using a

call

to
Invoke.

Hope this helps.


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

message news:%[email protected]...

I dispensed some advice and its bugging me that it may not be 100% accurate.

Worker threads should not touch main thread objects. Everybody knows that
but if you pass a reference to a form object to a worker thread and you
touch that form on the worker thread. All is well.

Is that right? Will all really be well? It's a reference to the form object.
The worker thread is still modifying the main threads object,

reference

 

[Alvin Bruney]

That's exactly what I recommended but I guess I want to advance my knowledge
of the model, how it behaves and what are the limits I can push it to.

Where can I read more about threading and controls as it applies to webforms
(not interested in winforms)? Or a book perhaps? My knowledge of this model
is no longer sufficient to satisfy my curiosity.

I'm aware that precious little is out there concerning threading in webforms
while there is a ton on winforms. Even the more widely read books purposely
shy away from this topic or set aside a line or two to discuss it.

For example, you said 'you can modify them on any thread you like (from what
I know)'.

Well how did you come across that piece of information?
I know it from getting burned by it. Learning the hardway is too expensive
so i'd rather read about it and save the frustration for something else.

regards

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits

Alvin,

Controls in ASP.NET do not follow the windows model, so you can modify
them on any thread you like (from what I know). However, you can not access
the HttpContext in other threads, as I believe that they are associated with
the threads that the page is processed on. If you want to access this
information from another thread, then I recommend you pass the HttpContext
along to that thread.

Hope this helps.


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

Right, I get that.
Now, does the same thing apply for session objects - which is where I was
headed in the first place? Is the instance of the HttpContext object owned
by the main thread? The line gets a little blury here for me. If the access
is done within the context of the global object, it is guaranteed to be
called correctly. (I also need confirmation on that, but I believe this is
the case).

But what if you just spawn a worker thread and want to touch session object.
How would I use a control invoke? Control.Invoke(pass in what here though?)
the param accepts a method of type delegate not an object.

Memory failed me, I was actually making the call in global and not on a
worker thread, but this got my curiosity up.

If you never run into problems in your scenario, then that's great

it would only be a matter of time before that would start failing, like
right after the product shipped usually.

regards

--


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
message news:[email protected]...

Alvin,


It is wrong. For a form object, even if access to the object was
synchronized (which it is not), the windows handle and all operations

on
it

(which the form encapsulates) requires that you make the call on the thread
where the element was created.

If you never run into problems in your scenario, then that's

great,
but

if you do, it's something that you could have avoided now by using a

call

to
Invoke.

Hope this helps.


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

message I dispensed some advice and its bugging me that it may not be 100%
accurate.

Worker threads should not touch main thread objects. Everybody knows that
but if you pass a reference to a form object to a worker thread and you
touch that form on the worker thread. All is well.

Is that right? Will all really be well? It's a reference to the form
object.
The worker thread is still modifying the main threads object,

reference

or
not, without using control invoke - that is, it isn't getting modified
from
the thread owning the object in the correct way.

I'm not sure I now agree that this is safe. Infact I now realize

that
this

is absolutely wrong.
Any help here?