Comments 7
Скажите, а зачем вам возвращатся в тот поток из которого вызывали, если это не UI поток?
Ну разве что кто-то запустит непотокобезопасный код. Мне просто было интересно все это воспроизвести, практической пользы от этого мало.
Чтобы
await в консольном приложении работал, как ожидается, например.
Я сталкивался со следующей проблемой, когда надо было сделать несколько асинхронных вызовов к базе с помощью EF в ASP.NET приложении.
Суть проблемы в том, что контекст EF не является потокобезопасным, и более того он генерирует исключение, если обращение к контексту было создано из другого потока. В тоже время асинхронность вызова в ASP.NET подразумевает использование AspNetSynchronizationContext, который в свою очередь использует пул потоков, а это значит, что вызовы к контексту EF могут происходить из разных потоков. Поэтому в такой ситуации собственный SynchronizationContext не повредил бы.
Суть проблемы в том, что контекст EF не является потокобезопасным, и более того он генерирует исключение, если обращение к контексту было создано из другого потока. В тоже время асинхронность вызова в ASP.NET подразумевает использование AspNetSynchronizationContext, который в свою очередь использует пул потоков, а это значит, что вызовы к контексту EF могут происходить из разных потоков. Поэтому в такой ситуации собственный SynchronizationContext не повредил бы.
Мне кажется в предложенном решении есть race condition. Если новая задача прилетит между выполнением двух строк, то прилетевшая задача не выполнится пока не придёт следующая задача:
_eventReset.Reset();
_eventReset.WaitOne();
Sign up to leave a comment.
Пишем свой SynchronizationContext