[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #TLB-677315]: FW: Net CDF-4 Issues

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