Introducing thread-safety in lib.rs

[panosfol]

Our rust module currently is not thread safe, there are a lot of critical sections according to the output of valgrind --tool=helgrind.
The difficulty of introducing thread-safety in our rust module is that the mutex should be locked and unlocked from the C side of our codebase, since we cant create a new mutex inside our rust module.
Therefore I suggest an interface be created that will have the necessary functions of handling a mutex lock_mutex(), init_mutex(), destroy_mutex() etc. and just extern those functions to the Rust side. That way we can handle the mutex inside the rust library without worrying where the mutex is defined, created and destroyed.

[charmitro]

Should we include mutexes within the Rust module, or manage them externally? Is there a way to test and compare the performance impact of locking mechanisms implemented inside the Rust module versus outside of it?

[panosfol]

Yes after #74 is resolved, ill benchmark it with the mutex being handled internally and externally, and post the results here for further discussion.

[charmitro]

Panagiotis Foliadis ***@***.***> writes:

Yes after #74 is resolved, ill benchmark it with the mutex being handled internally and externally, and post the results here for further discussion. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

Noted.