asterixdb-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yingyi Bu (JIRA)" <>
Subject [jira] [Created] (ASTERIXDB-1947) Revisit thread safety in FileMapManager
Date Mon, 19 Jun 2017 22:26:00 GMT
Yingyi Bu created ASTERIXDB-1947:

             Summary: Revisit thread safety in FileMapManager
                 Key: ASTERIXDB-1947
             Project: Apache AsterixDB
          Issue Type: Improvement
          Components: STO - Storage
            Reporter: Yingyi Bu
            Assignee: Abdullah Alamoudi

Synchronizations on FileMapManager (e.g., synchronized register/unregister, and ConcurrentHashMap
for id2namemap and name2idmap) is added in change

However,  this class seems 50%-baked -- there are some synchronizations but there could be
inconsistency between id2nameMap and name2IdMap.  For example, register/unregister
are not atomic -- a caller can lookupFileId(...) while the file hasn't fully registered or
unregistered, and possibly open an non-existent file?

I think we probably don't want thread-safety for FileMapManager at all, since the call sites
anyway has to orchestrate multiple steps and make sure the bigger block is synchronized:
E.g. BufferCache.openFile(...):

synchronized (fileInfoMap) {
            if (fileMapManager.isMapped(fileRef)) {
                fileId = fileMapManager.lookupFileId(fileRef);
            } else {
                fileId = fileMapManager.registerFile(fileRef);
        return fileId;

Even if FileMapManager is thread-safe, it doesn't help and you still have to synchronized
on the big block to make sure atomicity of the sequence of isMapped/lookup/register.  Most
call sites have a similar pattern.  Thoughts?

This message was sent by Atlassian JIRA

View raw message