bug: computePixelHashSHA1 is unstable when multithreaded

[adambowen-foundry]

Description

The ImageBufAlgo.computePixelHashSHA1 function supports blocksize and nthreads parameters to allow the hash to be computed in parallel. Unfortunately when parallelised the results are unstable (presumably because the threads can return results in a non-deterministic order).

Consider the following script

import OpenImageIO as oiio

bs=64
nthreads=2
for i in range(1, 10):
    print(oiio.ImageBufAlgo.computePixelHashSHA1(oiio.ImageBuf(sys.argv[1]), blocksize=bs, nthreads=nthreads))

Running using BrightRings.exr yields a variety of hashes

$ python id.py BrightRings.exr
170C7F4BBD658CBDAFE3EF24F024A1EA1A2FD950
CA255D0D716E9EC4F8E9A1D23B48343B8250E626
3B4B2F827B7BA179F4294E95E37A6325F4B5DD06
52E7BA6AA88F9BE3609610015673DF37321CAEEF
20B1D7DB81FE35F942B1584ACCA2459687F7CC77
9E29AB1F28825024E74C72118F5EC846F908DFE7
3B4B2F827B7BA179F4294E95E37A6325F4B5DD06
7F8997A4372B5DCC7B31BAB2307C1C23456E94F1
3B4B2F827B7BA179F4294E95E37A6325F4B5DD06

Reducing the number of threads to 1 yields a consistent result 3B4B2F827B7BA179F4294E95E37A6325F4B5DD06.

I've only tried this on MacOS.

OpenImageIO version and dependencies

Please run oiiotool --buildinfo and paste the output here.

OIIO 3.1.15.0 | MacOS/ARM
    Build compiler: Apple clang 15.0 | C++17/201703
    HW features enabled at build: neon
    No CUDA support (disabled / unavailable at build time)
Dependencies: BZip2 1.0.8, DCMTK NONE, expat 2.6.3, FFmpeg NONE, fmt 12.1.0, Freetype 2.14.1, GIF 5.2.1, Imath 3.1.10, JPEG 80, JXL NONE, libdeflate 1.23, Libheif NONE, libjpeg-turbo 3.1.2, LibRaw NONE, libuhdr 1.4.0, minizip-ng 4.0.10, OpenColorIO 2.5.1, OpenCV
    NONE, OpenEXR 3.3.5, OpenGL, OpenJPEG 2.5.4, openjph NONE, PNG 1.6.50, Ptex NONE, Ptex NONE, pybind11 3.0.1, pystring NONE, Python3 3.10.11, Qt5 NONE, Qt6 NONE, Robinmap 1.4.0, TBB NONE, TIFF 4.7.1, WebP 1.6.0, yaml-cpp 0.8.0, ZLIB 1.2.12, ZLIB 1.2.12

This is a standard build from PyPi.

To Reproduce

Call oiio.ImageBufAlgo.computePixelHashSHA1 on an image with blocksize>0 and nthreads>1

The hash will vary.

[lgritz]

Weird! It's obviously not supposed to do that. Looking into it.

[lgritz]

Curiously, it's always the first iteration that differs from the others. Hmmm.

[lgritz]

Wow, computePixelHashSHA1 turns out to be ok, but this exposed an embarrassing race condition in the guts of ImageBuf that it's kind of shocking had not previously been noticed. Thanks so much for reporting this with a clear repro. Fix incoming.

[lgritz]

Actual fix is #5325