Some overzealous locking to track down RequestObject related crashes.
bc0fa4d689 wrongly locked the current event loop's
request_invalidation_lock instead of the invalidation's list lock.
Also Abstract UI is able to delete requests concurrently with with
EventLoop invalidation.
e.g. PortManager::PortRegisteredOrUnregistered and GlobalPortMatrixWindow
so the lock needs to be exposed.
If this solves various issues, mutexes should to be consolidated
(request_buffer_map_lock + request_invalidation_lock) and be chosen
such that there is as little contention as possible.
During initial session load it's possible that two threads call
PBD::notify_event_loops_about_thread_creation() simultaneously
(in particular the process threads). This can lead to an
endless loop in stl_tree.h when assigning thread_buffer_requests[key]
Now we only have WriteLocks.. unless some better solution comes up a
Mutex will do.
This new design will work even when threads that need to receive
messages from RT threads are created *after* the RT threads. The
existing design would fail because the RT thread(s) would never
be known the later created threads, and so signals emitted by the
RT thread and causing call_slot() in the receiver would end up
being enqueued using a lock-protected list. The new design ensures
that communication always uses a lock-free FIFO instead
being logged before they are handled, and to invalidate them all rather
than just the last one. Fixes shutdown problems when the PortMatrix has
been opened during the session, during which PortRegisteredOrUnregistered
is emitted quite heavily.
git-svn-id: svn://localhost/ardour2/branches/3.0@6852 d708f5d6-7413-0410-9779-e7cbd77b26cf
