-
Notifications
You must be signed in to change notification settings - Fork 7k
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
kernel: Add support for stopping workqueues #82614
Merged
kartben
merged 3 commits into
zephyrproject-rtos:main
from
Mattemagikern:k_work_queue_stop
Dec 12, 2024
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Probably would be best to rename to |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,59 @@ | ||
/* | ||
* Copyright (c) 2024 Måns Ansgariusson <[email protected]> | ||
* | ||
* SPDX-License-Identifier: Apache-2.0 | ||
*/ | ||
|
||
#include <zephyr/kernel.h> | ||
#include <zephyr/ztest.h> | ||
|
||
#define NUM_TEST_ITEMS 10 | ||
/* In fact, each work item could take up to this value */ | ||
#define WORK_ITEM_WAIT_ALIGNED \ | ||
k_ticks_to_ms_floor64(k_ms_to_ticks_ceil32(CONFIG_TEST_WORK_ITEM_WAIT_MS) + _TICK_ALIGN) | ||
#define CHECK_WAIT ((NUM_TEST_ITEMS + 1) * WORK_ITEM_WAIT_ALIGNED) | ||
|
||
static K_THREAD_STACK_DEFINE(work_q_stack, 1024 + CONFIG_TEST_EXTRA_STACK_SIZE); | ||
|
||
static void work_handler(struct k_work *work) | ||
{ | ||
ARG_UNUSED(work); | ||
k_msleep(CONFIG_TEST_WORK_ITEM_WAIT_MS); | ||
} | ||
|
||
ZTEST(workqueue_api, test_k_work_queue_stop) | ||
{ | ||
size_t i; | ||
struct k_work work; | ||
struct k_work_q work_q; | ||
struct k_work works[NUM_TEST_ITEMS]; | ||
struct k_work_queue_config cfg = { | ||
.name = "test_work_q", | ||
.no_yield = true, | ||
}; | ||
|
||
zassert_equal(k_work_queue_stop(&work_q, K_FOREVER), -EALREADY, | ||
"Succeeded to stop work queue on non-initialized work queue"); | ||
k_work_queue_start(&work_q, work_q_stack, K_THREAD_STACK_SIZEOF(work_q_stack), | ||
K_PRIO_PREEMPT(4), &cfg); | ||
|
||
for (i = 0; i < NUM_TEST_ITEMS; i++) { | ||
k_work_init(&works[i], work_handler); | ||
zassert_equal(k_work_submit_to_queue(&work_q, &works[i]), 1, | ||
"Failed to submit work item"); | ||
} | ||
|
||
/* Wait for the work item to complete */ | ||
k_sleep(K_MSEC(CHECK_WAIT)); | ||
|
||
zassert_equal(k_work_queue_stop(&work_q, K_FOREVER), -EBUSY, | ||
"Succeeded to stop work queue while it is running & not plugged"); | ||
zassert_true(k_work_queue_drain(&work_q, true) >= 0, "Failed to drain & plug work queue"); | ||
zassert_ok(k_work_queue_stop(&work_q, K_FOREVER), "Failed to stop work queue"); | ||
|
||
k_work_init(&work, work_handler); | ||
zassert_equal(k_work_submit_to_queue(&work_q, &work), -ENODEV, | ||
"Succeeded to submit work item to non-initialized work queue"); | ||
} | ||
|
||
ZTEST_SUITE(workqueue_api, NULL, NULL, NULL, NULL, NULL); |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Pardon me.
If we allow task append to the queue continuously after setting
K_WORK_QUEUE_STOP_BIT
, the block will never be executed.Is it excepted?
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.
A pre-condition to the _stop(..) function is that the queue has already been plugged.
So the case you're thinking of is:
Would thread b. freeze indefenately?
Initially, maybe 👍
Question is if we should disallow that append of work if the K_WORK_QUEUE_STOP_BIT is set as well.
I'm not sure. How do you reason?
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.
Oh, I missed we need to call
k_work_queue_drain
before stoppingworkqueue
, but the design make me thinks about this scenario will happen?Base on doc
I think it is possible so we need to care about this problem. WDYT?
In general, I prefer
K_WORK_QUEUE_STOP_BIT
being isolated instead depend onK_WORK_QUEUE_PLUGGED_BIT
.K_WORK_QUEUE_STOP_BIT
is set.K_WORK_QUEUE_STOP_BIT
forever even if timeout avoid appendingwork
toworkqueue
and documented it.What do you and others think about this idea?
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.
Sounds like a great opportunity for additional test cases
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.
@TaiJuWu
Another option is to forbid the unplug function if
K_WORK_QUEUE_STOP_BIT
is set.Either thread B or C would return an error, depending on which accessed the queue first.
I believe this is the smallest change we could make to implement this feature. It shouldn't affect current use cases, what do you think?
@cfriedt Agreed!
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 case I'm making could still deadlock thread b, if the queue never drains the queue will continue to accept works.
So we probbably need the 2. You outlined earlier as well.
But that changes the behaviour of the queue & drain system slightly, is that ok?
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.
Sound great.
It is ok for me but we still need @andyross or other maintainers comfirm since the caller is time-sensitive.
By the way, I am not sure we need to call
k_work_queue_drain
beforek_work_queue_stop
by users is good api design or not.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.
Myself, being biased (haha), think it is neat :P The
queue_drain(..., true)
gives the user the knowledge that the works scheduled up to that point will be executed and in so doing letting free-routines kick in as to not casue memory leaks in the application.The k_work_queue_stop(...)
stopps the thread as soon as the last job has been processed.I'll commit the changes that we outlined here today :)
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.
I think we need to call
queue_drain(..., true)
ink_work_queue_stop
internally and setK_WORK_QUEUE_STOP_BIT
berforequeue_drain(..., true)
Is it possible in current design?
Additionally, System Workqueue should never stop I guess.
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 patch specifically addresses scenarios where stopping a workqueue becomes interesting, like in a couple of tests I have in mind.
I believe the patch aligns with the broader system goals. If this approach conflicts with project guidelines or expectations, I expect that the maintainers wil let me know shortly haha 🥲
I've just looked through the
kernel/work.c
file, it would be a neat addition, one less function call from the users to achive the same effect. What's stopping me is thek_work_queue_drain(...)
since the current implementation is blocking (K_FOREVER
) and to resolve that I would need to rework that function to include a timeout and then manage to make the timeout time be split between the draining & the stopping of the thread (the stopping of the queue would be, almost, instantanious at that point if we've passed the drain stage).@cfriedt @andyross How would you like me to proceede with:
_drain(..)
to include a timeout and incorperate parts of that function in the_stop(...)
or
_unplug(..)
and stop new works to be scheduled if the stop bit is set?Regarding the race-condition you're (@TaiJuWu) outlining I don't think it is a problem since the getting & setting of the flags are protected by the spin_lock, the winner of the spin_lock would dictate the outcome.