Fibers, what for?

[Alex Parrill via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 08:38:03 UTC, chmike wrote:
> Fibers don't need synchronization to access shared data. This 
> removes the overhead of synchronization and simplifies 
> "multitheaded" programming greatly.

This is misleading. Any sort of cooperative system needs 
synchronization when two or more tasks try to access the same 
data, whether those "tasks" are OS threads, fibers, different 
machines on a network, etc.

Fibers do make it easier, as no task can run in parallel with the 
current one and switching tasks is done explicitly via yield, 
effectively giving the current fiber exclusive access to the 
entire program state in between yields. But if you need to hold 
onto a resource across a yield, you will need the usual set of 
concurrency primitives, like locks.

(A practical example: making a commit using the Node.js libgit 
bindings involves several asynchronous steps, during which other 
tasks may access it. If you don't want anyone else messing with 
the Git repo while you are making a commit, you must protect the 
repo with a lock.)

Also note that Vibe.d, the largest fiber-based framework D has to 
offer, is capable of running several coroutines in parallel on 
multiple threads, meaning you must use the same level of 
synchronization as if you were using threads.