473,320 Members | 1,876 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Thread question (doubt)

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?

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
Nov 15 '05 #1
5 1195
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]
- mv*@spam.guard.caspershouse.com

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:%2****************@TK2MSFTNGP11.phx.gbl...
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?

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

Nov 15 '05 #2
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" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:%2****************@TK2MSFTNGP11.phx.gbl...
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?

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

Nov 15 '05 #3
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
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:uD**************@TK2MSFTNGP12.phx.gbl... 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]
- mv*@spam.guard.caspershouse.com

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:%2****************@TK2MSFTNGP11.phx.gbl...
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?

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


Nov 15 '05 #4
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]
- mv*@spam.guard.caspershouse.com

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:uW*************@TK2MSFTNGP11.phx.gbl...
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
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote

in message news:uD**************@TK2MSFTNGP12.phx.gbl...
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]
- mv*@spam.guard.caspershouse.com

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in message news:%2****************@TK2MSFTNGP11.phx.gbl...
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?

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



Nov 15 '05 #5
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
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:Om**************@TK2MSFTNGP11.phx.gbl...
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]
- mv*@spam.guard.caspershouse.com

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:uW*************@TK2MSFTNGP11.phx.gbl...
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
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote

in
message news:uD**************@TK2MSFTNGP12.phx.gbl...
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]
- mv*@spam.guard.caspershouse.com

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote

in message news:%2****************@TK2MSFTNGP11.phx.gbl...
> 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?
>
> --
>
>
> -----------
> Got TidBits?
> Get it here: www.networkip.net/tidbits
>
>



Nov 15 '05 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: David Sworder | last post by:
This message was already cross-posted to C# and ADO.NET, but I forgot to post to this "general" group... sorry about that. It just occured to me after my first post that the "general" group readers...
31
by: AlexeiOst | last post by:
Everywhere in documentation there are recommendations to use threads from thread pooling for relatively short tasks. As I understand, fetching a page or multiple pages (sometimes up to 50 but not...
2
by: cottonviking | last post by:
Greetings, all! I've been pondering the pitfalls of aborting a secondary thread in a service app I'm writing (VB, fx v1.1). Everything I've read so far pretty much dissuades one from aborting one...
23
by: Jeff Rodriguez | last post by:
Here's what I want do: Have a main daemon which starts up several threads in a Boss-Queue structure. From those threads, I want them all to sit and watch a queue. Once an entry goes into the...
7
by: Ram | last post by:
Hi, I have two threads, one parent thread containing UI and a child thread waiting for some events from the parent thread. Now, I have two issues: 1) to keep the child thread active till the end...
4
by: Geoff Jones | last post by:
Hi Have a form (form1) that starts a thread which has another form within it (form2). How can I send a message to this thread? For example, how can I send some text from Form1 to an TextBox in...
5
by: temp2 | last post by:
Hello, I have an app that reads data params from a stream and updates controls accordingly. The stream reader is on a different thread than the main thread that created the controls. I fully...
6
by: HolyShea | last post by:
All, Not sure if this is possible or not - I've created a class which performs an asynchronous operation and provides notification when the operation is complete. I'd like the notification to be...
13
by: arun.darra | last post by:
Are the following thread safe: 1. Assuming Object is any simple object Object* fn() { Object *p = new Object(); return p; } 2. is return by value thread safe?
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.