There is no need to preallocate request buffers for these threads - the event
loops that require them can allocate them when they discover and register the
pre-registered threads. This also means that event loops do not need to
register request buffer factories.
The old code assumed that the thread that created a request buffer for a given
signal-emitting thread would be the latter thread, and thus a thread-local
pointer to the request buffer could be used. This turns out not to be true: the
GUI thread tends to be responsible for constructing the request buffers for
pre-registered threads.
That mechanism has been replaced by using a RWLock protected map using
pthread_t as the key and the request buffer as the value. This allows any
thread to create and register the request buffers used between any other pair
of threads (because the lookup always uses a pthread_t).
The symptoms of this problem were a signal emitted in an audioengine thread
that was propagated to the target thread, but when the target thread scans its
request buffers for requests, it finds nothing (because it didn't know about
the request buffer). In a sense, the signal was successfully delivered to the
target thread, but no meaningful work (i.e the signal handler) is performed.
This kills 2 birds with 1 stone: Removes the necessity of locks
and makes call_slot() realtime safe (req->invalidation->requests list
push_back). On object destruction, the invalidation-record (IR) itself is
invalidated.
Invalidated IRs are pushed onto a trash-pool and deleted in the event-loop
of the invalidated object (GUI thread) once all requests that reference it
have been processed.
One last detail remains: PBD::signal connect should reference the IR
and disconnect unreference it. This will guarantee that signal emission
will not reference the IR while the pool trash is dropped.
While EventLoop::invalidate_request() does invalidate request in the
request-list. It does *not* invalidate requests in the
per-thread-request-ringbuffer(s).
The invalidation record cannot be deleted in EventLoop::invalidate_request
see 6b5891a78f.
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
