4 ms·
Evented pretty much gets rid of the need for locking and critical sections. How so? If I write two events that access the same data structure and both events f
by CountHackulus 16y ago
Evented pretty much gets rid of the need for locking and critical sections.
How so? If I write two events that access the same data structure and both events fire at the same time (totally possible in a concurrent world), I still seem some sort of locking on that data to guarantee consistency.
You may not need to write the locks explicitly, but they'll be there at least implicitly. Personally, I'd rather control my locks (allowing coarser grain access) than letting the compiler try and handle it. Exception safety will mean that they'll either version the function, use a transaction, or not be able to coalesce accesses.
- samstokes 16y agoI think he meant: Single-threaded entirely gets rid of the need for locking and critical sections (so long as you don't need exclusive access to a resource for longer than a single callback), and evented lets you recover some of the concurrency you lost by sticking to a single thread (if you're IO-bound and you code carefully). In a single-threaded event framework, even if two external events fire simultaneously, their callbacks will be serialised because there's only one thread to run them in, so it's as if they fired at slightly different times. There'll be some latency processing the "second" event of course, but not too much so long as the callback of the "first" event doesn't take long (hence the "code carefully" part).