Unify lock allocation and GIL release thresholds

XXHASH_LOCK_MAYBE_INIT allocated the lock at >= XXHASH_GIL_MINSIZE
while every GIL release check uses >, so an update of exactly 64KB
allocated a lock that was never used.  Align both at > XXHASH_GIL_MINSIZE
and update the README wording.

Author: ifduyue

README.rst

@@ -264,8 +264,8 @@ One-shot functions (``xxh32_digest``, ``xxh64_hexdigest``, ``xxh3_128_digest``,
 etc.) are stateless and always safe to call concurrently.
 
 On Python 3.13+ the lock is always active. On Python 3.9-3.12 the lock is
-created on the first ``update()`` of 64KB or more; smaller operations never
-release the GIL, so they are serialized by the GIL itself.
+created on the first ``update()`` of more than 64KB; operations of 64KB or
+less never release the GIL, so they are serialized by the GIL itself.
 
 Sharing a streaming hash object across threads is still discouraged: even
 with locking, the order in which concurrent updates are applied (and hence

src/_xxhash.c

@@ -47,10 +47,10 @@
 #  define XXHASH_LOCK_FIELD      PyThread_type_lock lock;
 #  define XXHASH_LOCK_INIT(o)    ((o)->lock = NULL)
 #  define XXHASH_LOCK_IS_ACTIVE(o)  ((o)->lock != NULL)
-/* Lazy allocation on first large update */
+/* Lazy allocation on first update large enough to release the GIL */
 #  define XXHASH_LOCK_MAYBE_INIT(o, len)                                 \
     do {                                                                 \
-        if ((o)->lock == NULL && (len) >= XXHASH_GIL_MINSIZE) {          \
+        if ((o)->lock == NULL && (len) > XXHASH_GIL_MINSIZE) {           \
             (o)->lock = PyThread_allocate_lock();                        \
             /* fail? lock stays NULL, fall back to non-threaded code. */ \
         }                                                                \