[gdal-dev] RFC 47 and Threading

[Even Rouault]

Selon Andre Vautour <andre.vautour at caris.com>:

> I want to start off by saying a big thanks to Blake for taking his time
> to tackle what can only be a very difficult problem.
>  From what I can observe, the current discussion seems to be around the
> boundary of who should be responsible for ensuring thread safety around
> the block cache. The core of GDAL versus the individual drivers.

The core will necessarily have to know about thread-safety because the block
cache is there. The discussion is more whether the drivers must also necessary
be thread aware, or if core mechanisms are sufficient to hide this detail to the
drivers. And potentially offering to drivers a mechanism to deal themselves with
thread-safety if they can have a more optimized implementation than the default
one.

> While I
> see why such a conversation is important, as far as I am concerned, the
> most important part should be how it affects users of GDAL at the
> interface level.

Agreed.

> That is, if an application that is threaded is trying
> to use GDAL, how does it ensure thread-safety? What you have to keep in
> mind is that having some parts of the library not thread-safe basically
> just pushes the mutexing/locking to the calling applications.

Not necessarily. That's what I suggested in my previous email : if the costs of
the mutex are not too expensive for non-threaded usage, then the API could
systematically return thread-safe versions, that are potentially wrapped by
GDALDatasetThreadSafe

>
> Also, while it is important to document thread-safety limitations, might
> I suggest adding thread-safe related capabilities (TestCapability),
> especially if all drivers do not end-up having the same thread-safety
> constraints.

That might be a solution, although not ideal from a usability point of view (if
we come with something more complex that non-thread-safe vs thread-safe, that
might be difficult to understand by users of GDAL API), and from a
GDAL-developer point of view as well (need to assess thread-safety for each
driver).
There can have subtelties : imagine that the VRT driver is made to be thread
safe, but uses sources of drivers that might be not thread safe...

>
> I personally do not see a GDALDatasetThreadSafe wrapper as adding much
> complexity. For instance, if you were to add a capability that indicates
> if a driver is inherently thread-safe, you could add a new open method
> to open a dataset in a thread-safe way with something like the following
> pseudocode:
>
> DataSet OpenThreadSafe(GDALOpenInfo openInfo)
> {
>      DataSet dataSet = Open(openInfo);
>
>      if (!dataSet.TestCapability(THREAD_SAFE))
>      {
>           dataSet = wrapWithThreadSafeWrapper(dataSet);
>      }
>
>      return dataSet;
> }

Yes, that's similar to what I imagined with my idea of GDAL_OF_THREADSAFE open
flag.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com