Difference between blocking and non blocking statements with intra-assignment delay

Asynchronous Asynchronous literally means not synchronous. Email is asynchronous. You send a mail, you don't expect to get a response NOW. But it is not non-blocking. Essentially what it means is an architecture where "components" send messages to each other without expecting a response immediately. HTTP requests are synchronous. Send a request and get a response.

Non-Blocking This term is mostly used with IO. What this means is that when you make a system call, it will return immediately with whatever result it has without putting your thread to sleep (with high probability). For example non-blocking read/write calls return with whatever they can do and expect caller to execute the call again. try_lock for example is non-blocking call. It will lock only if lock can be acquired. Usual semantics for systems calls is blocking. read will wait until it has some data and put calling thread to sleep.

Event-base This term comes from libevent. non-blocking read/write calls in themselves are useless because they don't tell you "when" should you call them back (retry). select/epoll/IOCompletionPort etc are different mechanisms for finding out from OS "when" these calls are expected to return "interesting" data. libevent and other such libraries provide wrappers over these event monitoring facilities provided by various OSes and give a consistent API to work with which runs across operating systems. Non-blocking IO goes hand in hand with Event-base.

I think these terms overlap. For example HTTP protocol is synchronous but HTTP implementation using non-blocking IO can be asynchronous. Again a non-blocking API call like read/write/try_lock is synchronous (it immediately gives a response) but "data handling" is asynchronous.

Of course this violates my coding guideline #3: http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf) but it will work.

The reason to avoid using nonblocking assignments to code combinational logic is simulation performance. In Munkymorgy's example, after the always block triggers, you will evaluate the right-hand-side (RHS) of all of the equations, go back to the top of the always block, update the LHS of the equations, which will again trigger the always block, which will again force the simulator to evaluate the RHS of the equations, go to the top of the always block, then update the LHS of the equations. For larger blocks, this could cause multiple iterations through the always block, with the corresponding simulation penalty.

In your simple 1-line example, there is no internal simulation penalty, but there may be cross-assignment penalties elsewhere.

Good coders use consistently good coding habits. I would change the code. If changing the code breaks the simulation results, then there are additional bad coding habits buried elsewhere in the code. The code should not be that fragile.