mutex 'er up

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.
This commit is contained in:
Robin Gareus 2016-12-13 23:46:55 +01:00
parent 176625d9e0
commit fa07233a17
6 changed files with 16 additions and 6 deletions

View file

@ -77,10 +77,12 @@ class MyEventLoop : public sigc::trackable, public EventLoop
}
Glib::Threads::Mutex& slot_invalidation_mutex() { return request_buffer_map_lock; }
Glib::Threads::Mutex& request_invalidation_mutex() { return request_invalidation_lock; }
private:
Glib::Threads::Thread* run_loop_thread;
Glib::Threads::Mutex request_buffer_map_lock;
Glib::Threads::Mutex request_invalidation_lock;
};
static MyEventLoop *event_loop;