This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Coy, > I currently have a semaphore based on when a thread opens and closes > a NetCDF file. When the first thread opens/creates a NetCDF file, it > locks the semaphore and when it closes the file, it unlocks the > semaphore. Thus no other thread can open or create a NetCDF file > while the semaphore is locked. ... Sorry, I guess I misunderstood you. I thought your semaphores were per file, so they prevented another thread from open/close of the same file, but not from open/close of a different file. It sounds like your semaphore would even prevent two different threads from opening two different netCDF files at the same time, which is needed to make sure they don't both try to add to the same open file list at the same time. > I would assume that would be enough > to ensure two threads do not make NetCDF calls at the same time. But > you mentioned that the NC list might be corrupted because it is > being updated after the file is closed, which could be at the same > time another thread is allowed to open/create a NetCDF file. I agree, that should be enough to make sure the open file list doesn't get corrupted. I don't recall mentioning that the NC list could be corrupted by anything except simultaneous create, open, or close of netCDF files, but I may have been unclear. From what you have said, it sounds like I guessed wrong in speculating that the NC list might have become corrupted as a way to explain the problems you are seeing. > If this is true, how can I know when the NetCDF library has > completed all of it's actions after the file has been closed so that > I can allow another thread to open/create another NetCDF file. The operating system can delay flushing a file's buffers to the disk after the file is closed to optimize scheduling disk writes, but I don't think that should be relevant to this problem. There may be other data structures that are effectively global and contribute to the library not being thread-safe. For example, if a function updates a static variable whenever it is called, that variable is effectively global. I expect there are places where something is initialized only when called the first time, and that's implemented by updating and testing a static variable. Sorry, but at this point all I can say for sure is that the library is not thread safe. Your experience may indicate that it's not easy to make it thread safe by using locks of smaller granularity than the whole library, without rewriting it to be thread safe from the outset. --Russ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: TLB-677315 Department: Support netCDF Priority: Normal Status: Closed