[
https://issues.apache.org/jira/browse/TS-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14289937#comment-14289937
]
Alan M. Carroll commented on TS-3315:
-------------------------------------
That's not really the issue. If the code must have the lock, it should use
{{MUTEX_LOCK}} not {{MUTEX_TRY_LOCK}}. If using the latter it should check and
handle the unlocked case, not assert on failure. If we really need to check,
why not directly check the lock to see if it is (1) locked and (2) the locking
thread is this thread rather than trying to lock? E.g.
{code}
ink_assert(NULL == cont->mutex || cont->mutex->thread_holding == this_ethread())
{code}
> Assert after try lock
> ---------------------
>
> Key: TS-3315
> URL: https://issues.apache.org/jira/browse/TS-3315
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
> Reporter: Phil Sorber
>
> In iocore/cache/Cache.cc there is the following:
> {code}
> CACHE_TRY_LOCK(lock, cont->mutex, this_ethread());
> ink_assert(lock.is_locked());
> {code}
> Does it really make sense to try and assert when a try can fail?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
