When the counts were the only thing distinguishing gensyms, it made sense to keep global state and thread lock it. As described in #210, I later realized that wasn't good enough, because gensyms compiled in different sessions may be used together in the same program. I came up with gensym hashes to deal with that problem. Giving each reader instance its own state is no worse than using readers over multiple sessions.
It would also be more deterministic/reproducible if readers run on multiple threads didn't have to share global state. Even with the thread locking ensuring any given number is only allocated to one template per session, there's a race condition around which template is allocated which number when multiple threads are used.
Thread locking would then no longer be of much use. I'd just document reader instances as not particularly thread safe, and if you need to use them on multiple threads, each thread will need its own instance.
When the counts were the only thing distinguishing gensyms, it made sense to keep global state and thread lock it. As described in #210, I later realized that wasn't good enough, because gensyms compiled in different sessions may be used together in the same program. I came up with gensym hashes to deal with that problem. Giving each reader instance its own state is no worse than using readers over multiple sessions.
It would also be more deterministic/reproducible if readers run on multiple threads didn't have to share global state. Even with the thread locking ensuring any given number is only allocated to one template per session, there's a race condition around which template is allocated which number when multiple threads are used.
Thread locking would then no longer be of much use. I'd just document reader instances as not particularly thread safe, and if you need to use them on multiple threads, each thread will need its own instance.