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

Prevent concurrency issues #1

Open
mbr opened this issue Mar 14, 2018 · 4 comments
Open

Prevent concurrency issues #1

mbr opened this issue Mar 14, 2018 · 4 comments
Assignees

Comments

@mbr
Copy link
Member

mbr commented Mar 14, 2018

There needs to be some mechanism, either at compile- or runtime that prevents some basic errors to be made, like opening two writers to the same database.

Currently, I am thinking of the following semantics:

  • Allow 0 or 1 writers at any time, regardless of the number of readers
  • Allow any number of readers at any time.

This should be enforced across threads, but not processes (i.e. we're assuming we are the only application using the database, no lock files or similar needed).

Making sure the database is not Sync is probably the first step (it should be Send though?). Then, a runtime check, possibly through a wrapper type that Derefs, should be implemented, ultimately resulting in an instance of utimeseries::err::Error.

An alternative would be just using a Semaphore(1) / Mutex on an internal field to track writers, but that'd make the database a little less flexible down the road.

@mbr mbr assigned afck Mar 14, 2018
@afck afck assigned reiner-dolp and unassigned afck Mar 14, 2018
@reiner-dolp
Copy link
Contributor

reiner-dolp commented Mar 14, 2018

I am not sure what the goal is.

  • Should there be at most 1 writer that can be shared across threads?
    Or should there be at most 1 writer that is owned by/accessible from a single thread?
  • How should syncing between readers and writer behave?

@afck
Copy link
Contributor

afck commented Mar 14, 2018

I think there should be at most 1 writer that can be shared (i.e. it can be Send) across threads, i.e. each process can have at most 1 writer per time series (i.e. per file). Readers and writers don't need any special synchronization at all: The readers just read what's already on the disk, even if the writer is currently appending.
(Correct me if I'm wrong, @mbr.)

@mbr
Copy link
Member Author

mbr commented Mar 14, 2018

The writer needn't be Sync, but Send. If someone wants to share a writer, they can just put it into a Mutex or similar.

Syncing is not necessary, the data structure is built that it will only ever "see" completed writes while reading and it is append-only.

So, in summary: Max 1 writer, total, not thread-safe but Sendable. Any number of Readers, also Sendable.

@lweberk
Copy link

lweberk commented Nov 12, 2018

Would RwLock be of any help in that? Its kind of a Mutex which allows to acquire N readers but only 1 writer at a time.

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

No branches or pull requests

4 participants