Each article i read about SynchronizationContext talks on dealing with the form's controls. Is it the only purpose of the SynchronizationContext?
And I have to ask a basic thing also: Why cant I just do a lock on each control befor i use if the UI thread use it? why i need all this "SynchronizationContext" to communicate with the controls? I mean, isnt it a better way to communicate the controls? (I know it wont work).
Articles:
http://reedcopsey.com/2010/03/18/parallelism-in-net-part-15-making-tasks-run-the-taskscheduler/
..
SynchronizationContext can be used to execute work in any other thread's context.
There is a main caveat here though: the other thread needs to be prepared for that, e. g. by using a message pump, like the UI threads in WinForm and WPF do. Also, those UI threads always have a SynchronizationContext, while other thread types typically don't.
As for locking as an alternative, that would need a completely different design inside Microsoft classes. It might be possible, though it might also result in threads blocking for a long time when waiting. I think it would open a lot of possibilities for misuse.
This article on codeproject is rather helpful, like https://stackoverflow.com/a/4107653/586754.