New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RNG on native needs to consider thread safety #86

Open
kyonifer opened this Issue Oct 30, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@kyonifer
Owner

kyonifer commented Oct 30, 2018

Right now on K/native we currently just allow multiple threads to access the same mutable state, which will probably error out.

We need some sort of thread-safe solution using K/native's threading paradigm. For example, using native's worker threads that return frozen memory to be copied into mutable matrices on each thread.

@peastman

This comment has been minimized.

Contributor

peastman commented Oct 31, 2018

This might just be a matter of documentation: make it clear that KomaRandom is not thread safe on Native and you shouldn't share a single generator between threads. That seems to be the main principle behind threading on native: never have any mutable object accessible by two threads at the same time. The library and compiler work fairly hard to prevent you from doing it accidentally.

@kyonifer

This comment has been minimized.

Owner

kyonifer commented Oct 31, 2018

I think we absolutely should support threadsafe rng on native. By that I mean that calls to the top-level functions randn and rand should be possible from multiple threads (k/native workers) concurrently. Right now that won't fly because they are using shared mutable state underneath. But I don't believe there's any reason we couldn't have thread-local instances that each worker would call into when they accessed the top-level function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment