Understanding gunicorn's async worker concurrency model

An event loop is a cooperative scheduler. In a cooperative scheduler, contrary to a the linux kernel scheduler, the current running code decides when to "sleep" to allow another code to execute, so at any point in time only one code is running just like on a single core CPU. The turnmoil about parallelism and concurrency makes it look like the event loop may not have the same issues as a code based on POSIX threads, kind of True, still, only one code is running at any point in time, it's not possible to read broken values, still you need to manage states correctly possibly requiring the use of non-POSIX locks because before an asynchronous callback is called, states might have changed.