-
Notifications
You must be signed in to change notification settings - Fork 18
Add futex support #422
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
base: master
Are you sure you want to change the base?
Add futex support #422
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary of Changes
Hello @kamilaboba123, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request introduces fundamental support for futex-based synchronization mechanisms into the library. It provides direct API calls for futex wait and wakeup operations and demonstrates their usage by implementing a simple userspace mutex. This change lays the groundwork for more efficient and robust concurrency control within the system.
Highlights
- New Futex API: I've introduced a new header file,
include/sys/futex.h
, which declares thephFutexWait
andphFutexWakeup
functions. These functions provide the core API for interacting with futex (Fast Userspace Mutex) syscalls, enabling low-level synchronization primitives. - Simple Mutex Implementation: I've added a basic mutex implementation,
mymutex_t
, defined ininclude/sys/mymutex.h
and implemented insys/mymutex.c
. Thismymutex_t
leverages the newly exposedphFutexWait
andphFutexWakeup
functions, along with atomic operations, to providemm_lock
andmm_unlock
functionality. - Build System Integration: The
sys/Makefile
has been updated to include the newmymutex.o
object file, ensuring that themymutex
implementation is compiled and linked into the system library.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command>
or @gemini-code-assist <command>
. Below is a summary of the supported commands.
Feature | Command | Description |
---|---|---|
Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/
folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
The pull request introduces library support for futex syscalls and a simple mutex implementation based on them. There are critical type-safety issues in the mymutex
implementation due to mismatches between int
, unsigned int
, and the uint32_t
expected by the futex functions. These issues could lead to undefined behavior and portability problems. Additionally, a header file is missing a necessary include. Recommendations focus on correcting these type issues by consistently using atomic_uint32_t
and uint32_t
, and on fixing the missing include.
00e1235
to
46f9f67
Compare
2907b16
to
5620860
Compare
d94449b
to
e81822e
Compare
/gemini review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces support for futex-based synchronization primitives, replacing the previous implementations of mutexes and condition variables. The changes are extensive, touching header files and the core threading logic. My review has identified several critical issues, including a buggy spinlock implementation, an incorrect handle calculation in mutexTry
, and a race condition in resourceDestroy
. I've also pointed out some medium-severity issues related to code maintainability, error handling, and potential performance problems. These issues should be addressed to ensure the correctness and robustness of the new synchronization mechanisms.
} | ||
|
||
|
||
/* TODO: Recursive mutexes are not handled currently */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This TODO correctly notes that recursive mutexes are not handled. However, the mutex_t
struct (defined at line 79) contains a recursive_counter
field which is never used. This can be misleading for future developers. Please consider either implementing recursive mutexes or removing the recursive_counter
field to avoid confusion.
} | ||
|
||
|
||
/* TODO: this code probably should be in sys/interrupt.c, but this is ok for now */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
e81822e
to
fe1d188
Compare
017c575
to
99fa56e
Compare
|
||
|
||
#include <sys/types.h> | ||
#include <stdint.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it needed?
/gemini review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces support for futexes and implements mutexes and condition variables based on them. The implementation is a good step forward but contains a critical bug in mutexTry
that needs to be fixed. Additionally, there are some design considerations regarding the use of fixed-size resource pools that may impact scalability, and a potential unintended change in the default behavior of condition variables. Overall, the changes are valuable but require attention to these points before merging.
#define MUTEXES_SIZE 100 | ||
#define CONDS_SIZE 100 | ||
|
||
|
||
struct { | ||
spinlock_t spinlock; | ||
mutex_t items[MUTEXES_SIZE]; | ||
} mutexes = { 0 }; | ||
|
||
|
||
struct { | ||
spinlock_t spinlock; | ||
cond_t items[CONDS_SIZE]; | ||
} conds = { 0 }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The use of fixed-size global pools for mutexes and condition variables (100 of each) introduces a hard limit on the number of synchronization objects the system can create. This could be a problem for applications that require a large number of these objects.
Consider the following improvements:
- Dynamic Allocation: Use
malloc
to allocatemutex_t
andcond_t
objects on demand. This would remove the hard limit and make the system more scalable. - Configurability: If static allocation is a requirement, consider making the pool sizes (
MUTEXES_SIZE
,CONDS_SIZE
) configurable at build time. - Efficient Allocation: The current
reserveMutex
andreserveCond
functions use a linear scan to find a free slot. For larger pools, a more efficient mechanism like a free list would improve performance.
int condCreate(handle_t *h) | ||
{ | ||
return condCreateWithAttr(h, NULL); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new implementation of condCreate
changes the default clock type for condition variables. The previous implementation used PH_CLOCK_RELATIVE
as the default. The new version calls condCreateWithAttr
with NULL
attributes, which results in the clock type being initialized to 0
. If 0
is not equivalent to PH_CLOCK_RELATIVE
, this constitutes a silent change in behavior for any code that uses condWait
with a timeout and relies on the default clock type. To maintain backward compatibility, the previous default behavior should be preserved.
int condCreate(handle_t *h)
{
static const struct condAttr defaultAttr = { .clock = PH_CLOCK_RELATIVE };
return condCreateWithAttr(h, &defaultAttr);
}
74eddbb
to
071b61c
Compare
071b61c
to
a816ad9
Compare
Add library support for futex syscalls and synchronization mechanisms based on them.
Description
Add declarations for phFutexWait() and phFutexWakeup(),
implement a simple mutex - mymutex_t
Motivation and Context
Types of changes
How Has This Been Tested?
ia32-generic-qemu
Checklist:
Special treatment