Closed KarolKolenda closed 9 years ago
There is possibly a deeper issue - internal locks are thread local, and the documentation mentions several times (e.g. in MDB_NOTLS)
A read-only transaction may span threads if the user synchronizes its use. Applications that multiplex many user threads over individual OS threads need this option.
Some synchronization is necessary on client side.
I am thinking about a custom scheduler and making all operations async. NetMQ has similar issues - underlying logic require sockets to work on the same thread. NetMQ uses a custom scheduler for that:
Oh, I am thinking only about a single transaction per thread - I am not spanning it across multiple threads. Once I guarded BeginTransaction, Commit, Abort and OpenDatabase with locks everything is fine. The only errors I got before were from c# collections of various managers (TransactionManager for instance) - nothing really to do with LMDB binary.
Saying all that your solution would be brilliant and would allow passing transactions between threads. BTW: You did great job with this library - it is really amazing.
@KarolKolenda not me, the author is Ilya :)
:+1: Akward - me be stupid :)
@KarolKolenda I agree the library is amazing, I have learned a lot from this implementation of native interop and from its design!
@KarolKolenda thank you! Defenitely this is a bug. Will fix soon.
It looks like BeginTransaction and Commit, Abort as well as OpenDatabase are not thread safe. They are probably safe on LMDB side but c# support classes like TransactionManager uses HashSet not wrapped with any lock. They fail when multiple readers are being created and destroyed on different threads in a short period of time.