There is still a potential problem.
Figure the following:
- thread A executes ENTER_HASHLIB while lock is NULL; therefore, thread
A has released the GIL and doesn't hold any lock
- thread B enters EVP_update with a large buffer (it can be there, since
A doens't hold the GIL)
- thread B allocates the lock, releases the GIL, and allocates the lock
- thread A continues running and arrives at LEAVE_HASHLIB; there,
self->lock is not NULL anymore, so it tries to release it; since it
hasn't acquired it before, this may block forever (depending on the
platform I assume)

To remove this possibility, the macros should probably look like:

    #define ENTER_HASHLIB(obj) \
        { \
            int __lock_exists = ((obj)->lock) != NULL; \
            if (__lock_exists) { \
                if (!PyThread_acquire_lock((obj)->lock, 0)) { \
                    Py_BEGIN_ALLOW_THREADS \
                    PyThread_acquire_lock((obj)->lock, 1); \
                    Py_END_ALLOW_THREADS \
                } \
            }

    #define LEAVE_HASHLIB(obj) \
            if (__lock_exists) { \
                PyThread_release_lock((obj)->lock); \
            } \
        }