By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,338 Members | 1,346 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,338 IT Pros & Developers. It's quick & easy.

Question regarding thread.

P: n/a
hi all,

Can someone tell me why can't we modify UI element directly from worker
thread.

Why we need to write delete of call invoke to modify ui element?

Thanks in advance.

May 16 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
"archana" <tr**************@yahoo.com> wrote:
Can someone tell me why can't we modify UI element directly from worker
thread.
Windows in Win32 have thread affinity. See here, for example:

http://blogs.msdn.com/oldnewthing/ar...10/479124.aspx
Why we need to write delete of call invoke to modify ui element?


I don't understand this question.

-- Barry
May 16 '06 #2

P: n/a
Hello archana,

a> Can someone tell me why can't we modify UI element directly from
a> worker thread.
a> Why we need to write delete of call invoke to modify ui element?

Because UI has one thread that process incoming events. If u click on window
that tread needs to respond to that event
and if its tied up with some intensive CPU work the UI thread isn't going
to be able to process those message and app is in
"not responding" state

---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche
May 16 '06 #3

P: n/a
All the UI components are designed for single thread (i.e. the *single UI
thread), and are not thread safe. It used to be possible, but still
incorrect, to update UI (sometimes) from other threads, but eventually you
got bit. 2.0 catches all attempts now and throws an exception. If your on
2.0, here is a good way to update UI from worker(s):
http://channel9.msdn.com/ShowPost.aspx?PostID=171594

--
William Stacey [MVP]

"archana" <tr**************@yahoo.com> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.com...
| hi all,
|
| Can someone tell me why can't we modify UI element directly from worker
| thread.
|
| Why we need to write delete of call invoke to modify ui element?
|
| Thanks in advance.
|
May 16 '06 #4

P: n/a
Hi,

thanks for your reply.

My question is why we need to write delegates or call invoke method to
update UI from worker thread. Say suppose i have one form containing
textbox and i want to update text of textbox from worker thread. To
update textbox i need to write delegete and call that delegate in
worker thread even if my thread procedure can access textbox directly.

If you can tell me reason behind this then it will be helpful for me.

Thanks.

Barry Kelly wrote:
"archana" <tr**************@yahoo.com> wrote:
Can someone tell me why can't we modify UI element directly from worker
thread.


Windows in Win32 have thread affinity. See here, for example:

http://blogs.msdn.com/oldnewthing/ar...10/479124.aspx
Why we need to write delete of call invoke to modify ui element?


I don't understand this question.

-- Barry


May 19 '06 #5

P: n/a
"archana" <tr**************@yahoo.com> wrote:
My question is why we need to write delegates or call invoke method to
update UI from worker thread. [...]

If you can tell me reason behind this then it will be helpful for me.


I told you the reason - windows in the Windows operating system have
thread affinity, which means that they must be accessed on the thread
they were created on.

If the Framework tried to do locking and marshalling of all operations
itself, there would be lots of problems:

1) You could be lulled into a false sense of security because there
would be the risk of deadlock if an operation invoked an event and that
event tried to access a resource the worker thread was holding.

2) Operations wouldn't be "atomic" in any sense and could be interleaved
with operations on the main UI thread. For example, changing the width
to x and height to y of a control via two property accesses could be
interleaved with a similar change on the main UI thread (x2, y2),
resulting in a size of (x, y2) or (x2, y).

3) Most applications would run slower because applications which ran
their UIs only on the UI thread would have to go through locking which
they didn't need.

4) How could you delete a control (i.e. dispose it or remove it from the
relevant components / controls collection) and be sure that the other
thread isn't iterating through that collection while you did it? You'd
have to lock() on something, which implies that the other thread would
also have to lock() on something. That implies that every simple
application would have to lock on everything that needs some kind of
atomic access just so it would be future-proof for possible
multi-threading in the future. Requiring simple applications to be aware
of multi-threading and be littered with locks would not be a good
implementation choice, IMHO.

-- Barry

--
http://barrkel.blogspot.com/
May 19 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.