Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WEAK_SCOPED_MUTEX_LOCK/WEAK_MUTEX_TRY_LOCK revisited #11100

Open
masaori335 opened this issue Feb 27, 2024 · 1 comment
Open

WEAK_SCOPED_MUTEX_LOCK/WEAK_MUTEX_TRY_LOCK revisited #11100

masaori335 opened this issue Feb 27, 2024 · 1 comment
Assignees
Milestone

Comments

@masaori335
Copy link
Contributor

WEAK_SCOPED_MUTEX_LOCK and WEAK_MUTEX_TRY_LOCK are introduced to allow the mutex to be a nullptr.

// A weak version of the SCOPED_MUTEX_LOCK macro, allows the mutex to be a nullptr.
#ifdef DEBUG
#define WEAK_SCOPED_MUTEX_LOCK(_l, _m, _t) WeakMutexLock _l(MakeSourceLocation(), (char *)nullptr, _m, _t);
#else // DEBUG
#define WEAK_SCOPED_MUTEX_LOCK(_l, _m, _t) WeakMutexLock _l(_m, _t);
#endif // DEBUG

Typical usage is below.

WEAK_SCOPED_MUTEX_LOCK(lock, m_cont->mutex, this_ethread());
return m_cont->handleEvent(event, edata);

However, if we take a look at the Continuation::handleEvent in this case, it has a release assert of the mutex.

TS_INLINE int
handleEvent(int event = CONTINUATION_EVENT_NONE, void *data = nullptr)
{
// If there is a lock, we must be holding it on entry
ink_release_assert(!mutex || mutex->thread_holding == this_ethread());
return (this->*handler)(event, data);
}

It looks like we don't have reason to use WEAK_ version to allow nullptr in many cases.

@masaori335 masaori335 added this to the 10.1.0 milestone Feb 27, 2024
@duke8253
Copy link
Contributor

Hmm, I need to think this through a bit. I'm referencing #5879 to keep track of related PRs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants