XtextDocumentLocker.notifyModelListenersOnUiThread() blocks UI thread waiting for lock

When an XtextDocument is updated using modify(...), listeners on the UI thread are notified about the change. The same happens when readOnly(...) or one of its derivatives had to reconcile the state before the operation.

XtextDocumentLocker.notifyModelListenersOnUiThread() then blocks the UI thread waiting for a lock using tryReadOnly(...). This happens when it is not already running in the UI-thread, so it re-acquires the lock inside an asyncExec(...) call on the UI thread.

If there is a long-running operation holding the lock, this blocks the UI thread until the operation is completed, causing the UI to be unresponsive in the meantime. Since locks are actually always exclusive, this also happens for contending read operations.

This is also somewhat related to https://github.com/eclipse/xtext/issues/2470, where the current behavior of notifyModelListenersOnUiThread() has also been identified as a potential cause for deadlocks.

Start with XtextDocumentLocker.notifyModelListenersOnUiThread() and trace its tryReadOnly() and asyncExec() behavior. Reproduce the issue with a long-running operation holding the lock, then verify that model-listener notification no longer leaves the UI thread blocked; compare the related discussion in issue 2470.