We need a good way to test the locking mechanism used by the change dispatch coordinator. A standalone test script, of which multiple instances can be run in parallel, should do the trick. Pseudo-code of the main test loop:
forever {
$state = $coordinator->selectClient();
$clientId = $state['chd_site'];
if ( !$clientId ) {
sleep( 1 );
continue;
}
assert( readTestValue( $clientId ) === 0 );
sleep( 1 );
assert( readTestValue( $clientId ) === 0 );
writeTestValue( $clientId, 1 );
sleep( 1 );
assert( readTestValue( $clientId ) === 1 );
writeTestValue( $clientId, 0 );
$state['chd_seen'] += 1;
$coordinator->releaseClient( $state );
}readTestValue and writeTestValue can be implemented based on any persistent storage with atomic access - SQL, a file, memcached...
Note that this WILL destroy the state of wb_changes_dispatch, so it should really be done on a dummy table or dummy database. Also note that there should be more instances of this script running than there are client wikis in the wb_changes_dispatch table.
Perhaps a fake in-memory wb_changes_dispatch table with a single entry would be sufficient; The different instances of the test script would not share the table and would be unable to use information in that table to coordinate - but they would still use the locking mechanism, probably even more so.