Skip to content

Atomic PUT in fifottl driver #30

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
May 28, 2020
Merged

Atomic PUT in fifottl driver #30

merged 1 commit into from
May 28, 2020

Conversation

adkuz
Copy link
Contributor

@adkuz adkuz commented May 28, 2020

Close #20

@akudiyar akudiyar merged commit 4feab2d into master May 28, 2020
@oleg-jukovec oleg-jukovec deleted the 20-put-transaction branch June 16, 2023 12:22
oleg-jukovec added a commit that referenced this pull request Aug 9, 2023
@oleg-jukovec
fifo: fix data race for put()/take() with vinyl
2f8a283 
put()/take() contains two parts:

1. Get a tuple from an index.
2. Insert a next tuple (with id based on the data from the first
   call)/update the current one.

For the vinyl engine it could lead to yield on the second step. As
result we could put a tuple with the same id or got the same task
multiple times.

This is a potential problem. It is very unlikely to get yield
on the second place because changes occur in the same place
in memory. So it is should not to be flushed from memory to disk
right after getting a tuple. But it could happen on practice, see a
problem with auto increment and concurrent lookups [1].

This issue has been fixed before for fifottl driver [2][3]. Here I
tried to fix it in a similar code style to make it easier to
maintain the code.

1. tarantool/tarantool#389
2. #28
3. #30
@oleg-jukovec oleg-jukovec mentioned this pull request Aug 9, 2023
Merged
oleg-jukovec added a commit that referenced this pull request Sep 6, 2023
@oleg-jukovec
fifo: fix data race for put()/take() with vinyl
ebfccd5 
put()/take() contains two parts:

1. Get a tuple from an index.
2. Insert a next tuple (with id based on the data from the first
   call)/update the current one.

For the vinyl engine it could lead to yield on the second step. As
result we could put a tuple with the same id or got the same task
multiple times.

This is a potential problem. It is very unlikely to get yield
on the second place because changes occur in the same place
in memory. So it is should not to be flushed from memory to disk
right after getting a tuple. But it could happen on practice, see a
problem with auto increment and concurrent lookups [1].

This issue has been fixed before for fifottl driver [2][3]. Here I
tried to fix it in a similar code style to make it easier to
maintain the code.

1. tarantool/tarantool#389
2. #28
3. #30
oleg-jukovec added a commit that referenced this pull request Sep 25, 2023
@oleg-jukovec
fifo: fix data race for put()/take() with vinyl
b8b15c9 
put()/take() contains two parts:

1. Get a tuple from an index.
2. Insert a next tuple (with id based on the data from the first
   call)/update the current one.

For the vinyl engine it could lead to yield on the second step. As
result we could put a tuple with the same id or got the same task
multiple times.

This is a potential problem. It is very unlikely to get yield
on the second place because changes occur in the same place
in memory. So it is should not to be flushed from memory to disk
right after getting a tuple. But it could happen on practice, see a
problem with auto increment and concurrent lookups [1].

This issue has been fixed before for fifottl driver [2][3]. Here I
tried to fix it in a similar code style to make it easier to
maintain the code.

1. tarantool/tarantool#389
2. #28
3. #30
oleg-jukovec added a commit that referenced this pull request Oct 31, 2023
@oleg-jukovec
fifo: fix data race for put()/take() with vinyl
4b1aa1b 
put()/take() contains two parts:

1. Get a tuple from an index.
2. Insert a next tuple (with id based on the data from the first
   call)/update the current one.

For the vinyl engine it could lead to yield on the second step. As
result we could put a tuple with the same id or got the same task
multiple times.

This is a potential problem. It is very unlikely to get yield
on the second place because changes occur in the same place
in memory. So it is should not to be flushed from memory to disk
right after getting a tuple. But it could happen on practice, see a
problem with auto increment and concurrent lookups [1].

This issue has been fixed before for fifottl driver [2][3]. Here I
tried to fix it in a similar code style to make it easier to
maintain the code.

1. tarantool/tarantool#389
2. #28
3. #30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@akudiyar akudiyar akudiyar approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Two 'put' requests which have been performed in a short time may get the same ID
2 participants
@adkuz @akudiyar