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

Working on reentrant lock migration #133

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jbescos
Copy link
Member

@jbescos jbescos commented Feb 16, 2024

@jbescos jbescos marked this pull request as draft February 16, 2024 07:33
head = f.getHead(h);
msg = record != null ? f.format(record) : "";
tail = f.getTail(h);
} finally {
fLock.unlock();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The synchronized here was just paranoia so that other threads couldn't split the head/format/tail. If the developer did something foolish like:

Handler first = ....
Handler second = ...
second.setFormatter(new CollectorFormatter(null, first.getFormatter(), null));
logger.addHandler(first);
logger.addHandler(second);

I would just eliminate the flock and if anyone reports a problem we'll just tell them to not let the target formatter escape collectorformatter.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't want to make any improvement in this PR rather than migrating to ReentrantLock because, in case I introduce a new bug, it will be more difficult to spot it.

It makes more sense for me to create a new PR with improvements, and then I can try to migrate to ReentrantLock here.

In this way, if there is a bug, we can try to reproduce it with 2 versions to know whether it is caused by ReentrantLock PR or synchronization improvements PR.

Copy link
Contributor

@jmehrens jmehrens Feb 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds reasonable. However there is not an equivalent transformation because synchronized(f) is acquiring the lock of 'f'. So if you are going more compatible, the get rid of 'fLock' and check if 'f' is a CollectorFormatter and aquire f.lock.lock() If it is not a CollectorFormatter, synchronize or don't. No fix for this case because 'f' can be anything.

Copy link
Contributor

@jmehrens jmehrens Feb 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think one option would be:

  1. Remove this.fLock.
  2. Use a local 'fLock' and assign it f.lock if f is a CollectorFormatter or our lock if not.
  3. Returning our lock is a minor waste but, keeps the code a little cleaner around lock and unlock.
       if (f != null) {
            ReentrantLock flock = f instanceof CollectorFormatter 
                                    ?  ((CollectorFormatter) f).lock : lock;
            fLock.lock();
            try {
                head = f.getHead(h);
                msg = record != null ? f.format(record) : "";
                tail = f.getTail(h);
            } finally {
                fLock.unlock();
            }
      } else {

Signed-off-by: Jorge Bescos Gascon <jorge.bescos.gascon@oracle.com>
@jmehrens jmehrens linked an issue Feb 18, 2024 that may be closed by this pull request
@jbescos
Copy link
Member Author

jbescos commented Feb 19, 2024

I am going to wait to see what happens with the synchronized blocks in JDK21+.

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

Successfully merging this pull request may close these issues.

Support for virtual threads
2 participants