Skip to content

Add lock for updating file size in OS memory provider #622

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

Conversation

ldorau
Copy link
Contributor

@ldorau ldorau commented Jul 19, 2024

Description

Add lock for updating file size in OS memory provider, because umfMemoryProviderAlloc() has to be MT-safe.

Checklist

  • Code compiles without errors locally
  • All tests pass locally
  • CI workflows execute properly

Add lock for updating file size in OS memory provider,
because umfMemoryProviderAlloc() has to be MT-safe.

Signed-off-by: Lukasz Dorau <[email protected]>
@ldorau ldorau requested a review from a team as a code owner July 19, 2024 11:24
Comment on lines +656 to +669
if (util_mutex_lock(lock_fd)) {
LOG_ERR("locking file size failed");
return -1;
}

if (*fd_size + extended_length > max_fd_size) {
util_mutex_unlock(lock_fd);
LOG_ERR("cannot grow a file size beyond %zu", max_fd_size);
return -1;
}

fd_offset = *fd_size;
*fd_size += extended_length;
util_mutex_unlock(lock_fd);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about something like this? It probably should have better performance, and we don't need extra locks.
I'm not very proficient with atomics, so it would be good if @pbalcer or @igchor check if my proposal is valid .

Suggested change
if (util_mutex_lock(lock_fd)) {
LOG_ERR("locking file size failed");
return -1;
}
if (*fd_size + extended_length > max_fd_size) {
util_mutex_unlock(lock_fd);
LOG_ERR("cannot grow a file size beyond %zu", max_fd_size);
return -1;
}
fd_offset = *fd_size;
*fd_size += extended_length;
util_mutex_unlock(lock_fd);
do {
size_t size = *fd_size;
if (size + extended_length > max_fd_size) {
LOG_ERR("cannot grow a file size beyond %zu", max_fd_size);
return -1;
}
fd_offset = *fd_size;
} while(!__sync_bool_compare_and_swap(fd_size, size, size + extended_lenght));

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does not work - another thread can update fd_size with exactly the same value ...

Copy link
Contributor

@lplewa lplewa Jul 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should not be a problem - as compare_and_swap checks for old value, and them updates it to new value. So even if one thread updates this value, second thread will detect it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, it should work.
But how would you do that on Windows? I do not know any equivalent of __sync_bool_compare_and_swap on Windows ...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All atomic functions are available on windows - just they have stupid names.
https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-interlockedcompareexchange64

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my 2 cents: since this isn't perf critical, I'd just leave it as is with the mutex. Atomics can be tricky to get right and make things more difficult to modify.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Piotr - since this is not the allocation path we should use the simplest solution

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Piotr - since this is not the allocation path we should use the simplest solution

This is an allocation path

@bratpiorka bratpiorka merged commit 6f74530 into oneapi-src:main Jul 23, 2024
63 checks passed
@ldorau ldorau deleted the Add_lock_for_updating_file_size_in_OS_memory_provider branch July 29, 2024 07:20
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

Successfully merging this pull request may close these issues.

5 participants