xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 46336] Synchronization fault in FontInfoFinder
Date Wed, 10 Dec 2008 20:23:53 GMT

--- Comment #5 from Andreas L. Delmelle <adelmelle@apache.org>  2008-12-10 12:23:51
PST ---

I think I found a partial solution to the issue. "Partial" means "safer, but
still not ideal"

I rewrote FontCache.getFontInfos() to something like:

CachedFontFile cff = getFontFile(embedUrl);
if (cff != null) {
  if (cff.lastModified >= lastModified) {
    return cff.getEmbedFontInfos();
  synchronized (changeLock) {
    //redo the fetch to make sure
    cff = getFontFile(embedUrl);
    if (cff != null) {
      if (cff.lastModified < lastModified) {
        //outdated entry, and we're the first one here, so...
        changed = true;
        return null;
      } else {
        //another thread already detected this, and reloaded
        return cff.getEmbedFontInfos();

synchronized (changeLock) {
  cff = getFontFile(embedUrl);
  if (cff != null) {
    //first fetch returned null, but now we do get one...
    //for simplicity, assume this entry will do
    return cff.getEmbedFontInfos();

return null

In the best case (font present & up-to-date), there's no synchronization
overhead. In the worst case, we would perform three fetches: one
non-synchronized (returning an outdated entry), a second synchronized
(returning null because another thread already removed the font), and a third
one returning... what exactly?

Now, it is still not ideal since there is absolutely no guarantee yet that the
thread that actually removed the entry will be done with reloading the font (in
FontInfoFinder.find()) in time for subsequent threads to obtain the new
entry... In theory it is still possible that multiple threads reload the font
in parallel, which should actually be avoided, IIC.
It does remain safe, since, although multiple threads reload the font, only one
of them will actually add the newer entry to the cache. (see

Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

View raw message