[gdal-dev] Call for review on RFC 101: Raster dataset read-only thread-safety

Laurențiu Nicola lnicola at dend.ro
Fri Sep 6 23:11:17 PDT 2024


Hi,

On Sat, Sep 7, 2024, at 01:34, Even Rouault via gdal-dev wrote:
> I just don't see how to do that. Even a mutex around file operations would not be sufficient since we'd want both Seek()+Read() to be atomic per thread. PRead() would solve that, but very few drivers or underlying libraries use PRead() (and there's no implementation of it for all file systems, like Windows file API which lacks it). Or one would need a VSIThreadSafeHandle that would maintain a per-thread position, but that would still involves locking around access to the underneath handle.
> 
Coming back to this, there are two ways to get something similar to pread() on Windows:

 - passing an OVERLAPPED struct to ReadFile without setting FILE_FLAG_OVERLAPPED. This is still synchronous [1], but reads from the offset you've specified. Unlike pread(), it updates the file pointer position on return, so it doesn't mix well with concurrent reads that don't pass in an offset.
 - mapping the file in memory and implementing it with memcpy(). It does incur an extra copy vs. pure mmap, but I don't think it's too bad [2]. Unfortunately, it's not great on 32-bit systems [3].

Laurentiu

[1] I don't want to be the one to open that can of worms
[2] I haven't used Windows in a while, but on Linux memcpy() uses SIMD, but copying memory between the kernel and the user doesn't
[3] Windows 11 dropped 32-bit CPU support, but 32-bit apps will still run
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240907/10d6fd5a/attachment.htm>


More information about the gdal-dev mailing list