Skip to content
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

Check on race conditions #268

Open
jrising opened this issue Apr 25, 2017 · 3 comments
Open

Check on race conditions #268

jrising opened this issue Apr 25, 2017 · 3 comments

Comments

@jrising
Copy link
Member

jrising commented Apr 25, 2017

Assume that there will be many (>10) threads with separate API instances, which may (though I try to avoid it) be near the same execution step in their use of DataFS. Please check that the following scenarios are handled gracefully:

  1. One instance begins downloading file A, and the next moment another instance requests the same file.

  2. Instance 1 checks for file A and determines that it does not need to download it because it is already in the cache; before it has a chance to copy it out, instance 2 deletes file A from the cache.

  3. Instance 1 is repeatedly accessing version 1 of file A, while instance 2 is repeatedly accessing version 2 of file A. Both have a caching policy of last-accessed.

@delgadom
Copy link
Member

I agree that once refactored we definitely must be able to handle all of these. However, I don't think we should use last-accessed for any of our systems. I think we should use 'all' or, if space constraints are a problem, 'latest'.

Furthermore, (3) seems to me to be a pathological case and, while it's important that DataFS behaves correctly under these circumstances, I don't see any problem if there is a significant performance penalty for behavior consistent with (3). Does that seem right to you?

@delgadom
Copy link
Member

@jgerardsimcock putting a pin in this - there's a way to lock fs objects across threads even outside of the core methods. Maybe there is something we could be doing to prevent simultaneous access across multi-step operations such as cache + read, for example.

http://pyfilesystem.readthedocs.io/en/latest/base.html

@jrising
Copy link
Member Author

jrising commented Apr 26, 2017

Agreed that performance penalties on (3) are fine. But it's not that pathological: It is fairly common for us to have two different versions of the same sector running at the same time. E.g., we are producing a set of results, and then find a way to improve one of the underlying datasets. Rather than kill the first one (since we might decide to not use the improvement in the end), we just spin up another set of runs with the other dataset.

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

No branches or pull requests

2 participants