Should I use SendMessage() or PostMessage() to manipulate UI controls?

[john_n]

I have a UI thread and two other worker threads, I want to manipulate the UI controls from the worker threads (set control text, get control text, resize window, etc.).
I'm not sure how to do that, should I use SendMessage() or PostMessage()?

I have read that there are two problems in using SendMessage():

- It could block the calling thread if the UI thread is busy doing something else.
- A deadlock can happen in certain situations (each thread could be waiting for a result from the other thread).

In my case, I don't really care about the worker threads being blocked, and also no deadlock will happen. So is there anything wrong in using SendMessage()?

[VictorN]

I have a UI thread and two other worker threads, I want to manipulate the UI controls from the worker threads (set control text, get control text, resize window, etc.).
I'm not sure how to do that, should I use SendMessage() or PostMessage()?

The general rule is: you should not to (I'd just say you must not!) manipulate the UI controls from the worker threads.
Instead, you should notify the main UI thread that it now can/have to update some controls because of some changes made within the worker thread.
See this great essay: Using Worker Threads

In my case, I don't really care about the worker threads being blocked, and also no deadlock will happen. So is there anything wrong in using SendMessage()?

Лucky you that no deadlock happened yet!
But it will, earlier or later happen if you will use SendMessage.

[john_n]

Лucky you that no deadlock happened yet!
But it will, earlier or later happen if you will use SendMessage.

So I cannot predict if a deadlock will happen? I mean if I am only sending a message from the worker threads to the UI thread and not the other way around also. How can a deadlock happen in this case?

[VictorN]

So I cannot predict if a deadlock will happen? I mean if I am only sending a message from the worker threads to the UI thread and not the other way around also. How can a deadlock happen in this case?

Did you read the essay I referred to?
If it would be not enough for you then:
https://www.google.ch/webhp?sourceid...ead%20deadlock

[john_n]

Did you read the essay I referred to?
If it would be not enough for you then:
https://www.google.ch/webhp?sourceid...ead%20deadlock

I have read this article before posting this question. And just now I have noticed that the answer is: A deadlock can be very hard to predict!

[VictorN]

I have read this article before posting this question. And just now I have noticed that the answer is: A deadlock can be very hard to predict!

Exactly!

[Igor Vartanov]

Oh, come on! Deadlock is just a deadlock. It can happen any time you appear reckless enough to not analyze the concequences of introducing synchronization among threads. Like in the article, when GUI thread decides to wait for worker threads completion. The same way it could happen between worker threads waiting for each other resources.

There's nothing that would be very hard to predict in there. This is not about prediction at all, it's more about developing a habit of analyzing any of your moves. Chess play, car drive - you never stop analyzing any of your moves, you prepare any of your maneuvers. Multithreading is a similar play of balancing your resources and obeying the rules.

[Igor Vartanov]

So I cannot predict if a deadlock will happen? I mean if I am only sending a message from the worker threads to the UI thread and not the other way around also. How can a deadlock happen in this case?

Typically, the scenario is rather straightforward, like you send a message that changes the control state, the control sends notification to its parent, that is being processed tries to acquire some sync resource your thread already has locked. Bang, you're dead.

While your control notification processing remains unaware of threads syncing, or there's no notifying at all (e.g. reading from control), you're safe to send messages from worker thread. The more syncing appears in use, the more tricky situations can happen. So, as long as the code stays not too much complex, you're most probably safe, as you can observe the picture in whole.

A sample

There is one other side effect related to sending messages from worker threads. You might be tempted to start updating your GUI from more than one thread, and sooner or later the code degrades to a level when you lose the vision of the entire picture, and eventually lose the control over GUI behavior. This is what you are to avoid by all means, no matter if this provokes deadlocks or not.

[OReubens]

The simple rule is... communication by whichever means between threads should be done in an asynchronous fashion. This is true for sending messages, but is equally true if you would use another form of communication.
Failure to do so is opening the door to all sorts of issues including but not limited to deadlocks.


The reality of the matter is unfortunately not so easy. There are cases where you need synchronous communication and you can safely do that if you are very very very careful about what and how you do that.

So you either have to be 110% sure of what you're doing, or you can go the safe route and simply avoid the issue by using asynchronous methods.

[Igor Vartanov]

The reality of the matter is unfortunately not so easy.

or you can go the safe route and simply avoid the issue by using asynchronous methods.

Whatever simplification you do (or you think you do), reality wins. It gets you every time. Always. Just a matter of time.