(race cond)

It was possible for one thread to interrupt a Data Definition Language 
statement and thereby get messages to the binlog out of order.  Consider:

Connection 1: Drop Foo x
Connection 2: Create or replace Foo x
Connection 2: Log "Create or replace Foo x"
Connection 1: Log "Drop Foo x"

Local end would have Foo x, but the replicated slaves would not.

The fix for this is to wrap all DDL and logging of a kind in the same mutex.  
Since we already use mutexes for the various parts of altering the server, 
this only entails moving the logging events down close to the action, inside 
the mutex protection.