3 ms·

How are you "asyncing" to the "backgroundworker" thread? Await? Task.run? Are you using a .Return? I can't see your code, but this sounds more like a misunders

How are you "asyncing" to the "backgroundworker" thread? Await? Task.run? Are you using a .Return? I can't see your code, but this sounds more like a misunderstanding of the requirements around a UI thread and the task scheduler than any issue with async. https://medium.com/rubrikkgroup/understanding-async-avoiding-deadlocks-e41f8f2c6f5d https://medium.com/rubrikkgroup/understanding-async-avoiding... And the below seems to be a correct implementation of your desired functionality. https://stackoverflow.com/questions/9868929/how-to-edit-a-writablebitmap-backbuffer-in-non-ui-thread https://stackoverflow.com/questions/9868929/how-to-edit-a-wr...

nighthawk648 7y ago
Yes, I don’t understand why original commenter is so angry about c#/.net. Maybe a bad experience? Async .net may have some pitfalls but it is overall versatile which was the original sentiment anyways...
nwallin 7y ago
First of all, your original post claimed that the official documentation is good. I posted an example of where the official docs are dumb and wrong. You posted a random blog article and a stack overflow answer as a rebuttal. Just so we're clear, you agree that the official documentation is dumb, wrong, and incomplete? Second, the "seems to be correct" article you linked is what we did. It's a sensible, logical solution to the problem. Which is why we wrote it that way to begin with. Hell, we might have copied it directly from that SO answer. It doesn't work. It deadlocks. You call out to the UI thread dispatcher, lock the object, then go back to doing stuff on a background thread. Some time later, the UI thread is updating the UI, and it tries to update your element, and it tries to lock on the lock object. (it can't, because it's already locked) Some time later, the background task is done. It schedules a task on the UI thread to unlock the object. There's a problem though: the UI thread is locked on a mutex. A single hardware thread cannot wait on both a mutex and the task queue at the same time. Deadlock. Just because it's the highest voted answer on SO doesn't mean that it isn't completely wrong. The second highest voted answer states that what the questioner is asking for is impossible. This answer is the correct one. Our least bad solution to this problem is to update a buffer owned by the background thread, and then use the UI thread to copy pixels from the background thread's buffer to the UI thread's buffer. Lock, copy the buffer, unlock, without ever relinquishing control of the UI thread. This solution is not ideal from a performance standpoint, but at least it doesn't deadlock. C#/.NET's async is fine if you're not doing anything more complicated than querying a database or paying data around on a socket. It falls down really hard if you start tickling its underbelly.

nighthawk648 7y ago

Yes, I don’t understand why original commenter is so angry about c#/.net. Maybe a bad experience? Async .net may have some pitfalls but it is overall versatile which was the original sentiment anyways...

nwallin 7y ago

First of all, your original post claimed that the official documentation is good. I posted an example of where the official docs are dumb and wrong. You posted a random blog article and a stack overflow answer as a rebuttal. Just so we're clear, you agree that the official documentation is dumb, wrong, and incomplete? Second, the "seems to be correct" article you linked is what we did. It's a sensible, logical solution to the problem. Which is why we wrote it that way to begin with. Hell, we might have copied it directly from that SO answer. It doesn't work. It deadlocks. You call out to the UI thread dispatcher, lock the object, then go back to doing stuff on a background thread. Some time later, the UI thread is updating the UI, and it tries to update your element, and it tries to lock on the lock object. (it can't, because it's already locked) Some time later, the background task is done. It schedules a task on the UI thread to unlock the object. There's a problem though: the UI thread is locked on a mutex. A single hardware thread cannot wait on both a mutex and the task queue at the same time. Deadlock. Just because it's the highest voted answer on SO doesn't mean that it isn't completely wrong. The second highest voted answer states that what the questioner is asking for is impossible. This answer is the correct one. Our least bad solution to this problem is to update a buffer owned by the background thread, and then use the UI thread to copy pixels from the background thread's buffer to the UI thread's buffer. Lock, copy the buffer, unlock, without ever relinquishing control of the UI thread. This solution is not ideal from a performance standpoint, but at least it doesn't deadlock. C#/.NET's async is fine if you're not doing anything more complicated than querying a database or paying data around on a socket. It falls down really hard if you start tickling its underbelly.