Показать сообщение отдельно
Старый 02.11.2016, 21:33   #21
h1dd3n
Бывалый
 
Аватар для h1dd3n
 
Регистрация: 19.06.2008
Сообщений: 679
Написано 264 полезных сообщений
(для 450 пользователей)
Ответ: Правильная организация Server<-> client

Если это поле используется как минимум в 2-ух потоках (например, в 1 читается, в другом пишется), то лучше сделать его volatile. Если оно к тому же читается многократно, его очень настоятельно рекомендуется сделать volatile.
Дело в том что оптимизирующий компилятор (JIT) может убрать цикл вообще, т.к. видит что там просто доступ к полю (он предположит что значение не меняется в другом потоке). Если отметишь как volatile, ты заставишь компилятор всегда читать из поля данные, то есть запретишь где-либо их кэшировать и т.д.

Вот нифига, выкидывает в другой поток, походу только UI возвращается.
Ну дак и отлично. Возвращается там где SynchronizationContext.Current это DispatcherSynchronizationContext. Контекст синхронизации задается у каждого потока. WPF для потока UI задал соответствующий контекст. У других потоков (которые из тредпула, например) SynchronizationContext.Current == null. Механизм await если видит что контекст синхронизации == null, просто продолжение планирует при помощи TaskScheduler.Current (который, если ты его не менял, скорее всего TaskScheduler.Default). А TashScheduler.Default все планирует на потоки из тредпула.
__________________
(Offline)
 
Ответить с цитированием
Эти 2 пользователя(ей) сказали Спасибо h1dd3n за это полезное сообщение:
RegIon (02.11.2016), St_AnGer (15.11.2016)