This is an archive of the discontinued LLVM Phabricator instance.

[NativeProcessLinux] Remove event mutex and clean functions using it
ClosedPublic

Authored by labath on May 8 2015, 5:10 AM.

Details

Summary

Since the former-TSC events are now processed synchronously, there is no need for to protect them
with a separate mutex - all the actions are now guarded by the big m_threads_mutex.

With the mutex gone, the following functions, no longer have any purpose and were removed:
NotifyThreadCreate: replaced by direct calls to ThreadWasCreated
NotifyThreadStop: replaced by direct calls to ThreadDidStop
NotifyThreadDeath: folded into StopTrackingThread
ResetForExec: inlined as it consisted of a single line of code
RequestThreadResume(AsNeeded): replaced by direct calls to ResumeThread
StopThreads -> removed, as it was never called

Diff Detail

Event Timeline

labath updated this revision to Diff 25309.May 8 2015, 5:10 AM
labath retitled this revision from to [NativeProcessLinux] Remove event mutex and clean functions using it.
labath updated this object.
labath edited the test plan for this revision. (Show Details)
labath added reviewers: ovyalov, chaoren.
labath added a subscriber: Unknown Object (MLST).
labath updated this revision to Diff 25313.May 8 2015, 5:18 AM

Small cleanups...

labath added inline comments.May 8 2015, 5:22 AM
source/Plugins/Process/Linux/NativeProcessLinux.cpp
2220–2221

Instead of locking m_threads_mutex at random places (here, MonitorSIGTRAP, MonitorSignal, ...) I would lock it just once, at the beginning of MonitorCallback. I think it will make more future-proof. I don't anticipate the slightly decreased concurrency will affect the performance in any way, and we may potentially increase stability, since then all MonitorCallback actions will be fully atomic.
What do you think?

ovyalov added inline comments.May 8 2015, 6:36 PM
source/Plugins/Process/Linux/NativeProcessLinux.cpp
2219–2220

s/NativeThreadLinux/NativeProcessLinux

2220–2221

Why do you need to acquire m_threads_mutex here?
It seems only GetThreadByID within ThreadDidStop needs to access m_threads but GetThreadByID by itself is synchronized with m_threads_mutex.

2220–2221

m_threads_mutex is supposed to synchronize access to m_threads collections and I'm not sure about expanding its synchronization scope - I'd rather keep scope of m_threads_mutex pretty fine-grained .

labath updated this revision to Diff 25457.May 11 2015, 3:50 AM

Fix typo, remove m_threads_mutex lock

source/Plugins/Process/Linux/NativeProcessLinux.cpp
2219–2220

Done.

2220–2221

I was worried about possible interactions with other functions executing concurrently and accessing other members of NPL/NTL: while the rest of ThreadDidStop does not access m_threads, it does some fairly complicated stuff with the thread that stopped and it is not immediately clear what are the possible interactions between this and any other code starting/stopping a thread (even a different thread) concurrently.

However, I have now realised that this code is already covered by Monitor::ScopedOperationLock, which makes sure monitor callbacks don't interleave with other threads. This makes the precautionary locking of m_threads unnecessary and I have removed it.

ovyalov accepted this revision.May 11 2015, 10:31 AM
ovyalov edited edge metadata.

Looks good.

This revision is now accepted and ready to land.May 11 2015, 10:31 AM
This revision was automatically updated to reflect the committed changes.