You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2024/04/10 15:18:00 UTC
[jira] [Commented] (MRESOLVER-522) File locking threads not entering critical region were "oversleeping"
[ https://issues.apache.org/jira/browse/MRESOLVER-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17835786#comment-17835786 ]
ASF GitHub Bot commented on MRESOLVER-522:
------------------------------------------
cstamas opened a new pull request, #461:
URL: https://github.com/apache/maven-resolver/pull/461
Instead to immediately give up and sleep, they will sit a while to enter critical region. This is important for "hot" locks.
Explanation: currently a "loser" will _immediately give up_ and will go to sleep 100ms if cannot enter critical region, even if winner exits critical region within next 5ms. The retry is needed to ensure that it is retried as much as given time/unit takes, that was before consumed by constant retries+sleeps. The logic still works, as if tryLock spends time/unit waiting on criticalRegion (which is possible only on VERY HIGHLY congested locks), there will be no retry happening.
Backport of 089796ba66d6f5f1a9d4fa7f797f613bae4f5373
---
https://issues.apache.org/jira/browse/MRESOLVER-522
> File locking threads not entering critical region were "oversleeping"
> ---------------------------------------------------------------------
>
> Key: MRESOLVER-522
> URL: https://issues.apache.org/jira/browse/MRESOLVER-522
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
> Reporter: Tamas Cservenak
> Assignee: Tamas Cservenak
> Priority: Major
> Fix For: 1.9.19
>
>
> Instead loser to immediately give up and sleep, should sit a while to enter critical region. This is important for "hot" locks.
> Explanation: currently a "loser" will _immediately give up_ and will go to sleep 100ms, even if winner exits critical region within next 5ms (so lost 95ms). The retry is needed to ensure that it is retried as much as given time/unit takes, that was before consumed by constant retries+sleeps. The logic still works, as if tryLock spends time/unit waiting on critical region (which is possible only on VERY HIGHLY congested locks), there will be no retry happening. Still, now it may sleep 5ms, and "win" once "original winner" left the critical region.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)