Hi Jin Pan, That's a great question. It sounds like we probably can remove the mutex, and it's definitely something worth trying (and then testing). I won't have time to do this in the immediate future, but removing the mutex and adding some tests that are analogous to the other multithreaded tests is something others who are comfortable with C++ could do as well. :-)
-greg On Tue, Oct 6, 2020 at 4:04 AM Jin Pan <jin....@postera.ai> wrote: > Hello rdkit-discuss, > > Commit 6cfd34 > <https://github.com/rdkit/rdkit/commit/6cfd347eafc713a66ba66051d2fc21046e60be58> > from > 2012 introduced a mutex to make the InChi code threadsafe. InChI v1.05 was > released in 2017, with release notes announcing better thread safety: > > As global and static objects may cause problems in a multi-threaded >> environment due to a possible race condition arising when more than one >> thread tries to access, they had to be removed from the InChI code. >> Corresponding changes were implemented. >> In particular, global variables associated with sorting and timing were >> replaced by objects which are passed to all functions that need access to >> the related data. Also, several functions which uses static variables that >> were initialized upon first entry into the function have been modified in >> order to avoid a race condition. >> Tests were performed for various applications using InChI Software >> Library and running up to 32 threads concurrently, and for datasets up to >> the whole Pubchem Compound set. No problems were encountered. >> > > Can we safely remove the mutex with the v1.05 InChI release, or do we > still consider that library to be thread unsafe? > > Best, > Jin Pan > _______________________________________________ > Rdkit-discuss mailing list > Rdkit-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rdkit-discuss >
_______________________________________________ Rdkit-discuss mailing list Rdkit-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
