workqueue 去掉timer，使用list排序处理方式 #9825

yuqingli05 · 2024-12-24T10:46:59Z

拉取/合并请求描述：(PR description)

[
并确认并列出已经在什么情况或板卡上进行了测试。
And confirm in which case or board has been tested. -->
bsp\qemu-vexpress-a9

为什么提交这份PR (why to submit this PR)

1、Fixed #9814
2、去掉每个work的定时器，能大量减少 work的内存占用，和性能优化

你的解决方案是什么 (what is your solution)

去掉work的 timer，只需要在 work线程里面延迟和同步即可

请提供验证的bsp和config (provide the config and bsp)

BSP: bsp\qemu-vexpress-a9

.config: 没用改动，直接 menuconfig 生成新的即可

action:

测试main函数如下

#include <stdint.h>
#include <stdio.h>
#include <rtthread.h>
#include <rtdevice.h>

struct rt_work work_test0;
struct rt_work work_test1;
struct rt_work work_test2;
struct rt_work work_test3;
struct rt_work work_test4;

void work_func(struct rt_work *work, void *work_data)
{
    rt_kprintf("name=%s tick=%d\n", (char *)work_data, rt_tick_get());
}

int main(void)
{
    rt_kprintf("Hello RT-Thread!\n");
    rt_thread_delay(100);

    rt_work_init(&work_test0, work_func, "work_test0");
    rt_work_init(&work_test1, work_func, "work_test1");
    rt_work_init(&work_test2, work_func, "work_test2");
    rt_work_init(&work_test3, work_func, "work_test3");
    rt_work_init(&work_test4, work_func, "work_test4");
   
    rt_kprintf("test rt_work_urgent tick=%d\n", rt_tick_get());
    rt_work_submit(&work_test0, 100);
    rt_thread_delay(10);
    rt_work_urgent(&work_test0);
    rt_thread_delay(100);
    
    rt_kprintf("test rt_work_submit tick=%d\n", rt_tick_get());
    rt_work_submit(&work_test3, 300);
    rt_work_submit(&work_test1, 100);
    rt_work_submit(&work_test4, 300);
    rt_work_submit(&work_test2, 100);
    rt_thread_delay(250);
    rt_work_submit(&work_test1, 50);
    rt_work_submit(&work_test2, 200);
    rt_thread_delay(300);

    rt_kprintf("test rt_work_cancel tick=%d\n", rt_tick_get());
    rt_work_submit(&work_test1, 50);
    rt_work_submit(&work_test2, 100);
    rt_work_submit(&work_test3, 150);
    rt_thread_delay(50);
    rt_work_cancel(&work_test2);

    return 0;
}

]

当前拉取/合并请求的状态 Intent for your PR

必须选择一项 Choose one (Mandatory):

本拉取/合并请求是一个草稿版本 This PR is for a code-review and is intended to get feedback
本拉取/合并请求是一个成熟版本 This PR is mature, and ready to be integrated into the repo

代码质量 Code Quality：

我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:

已经仔细查看过代码改动的对比 Already check the difference between PR and old code
代码风格正确，包括缩进空格，命名及其他风格 Style guide is adhered to, including spacing, naming and other styles
没有垃圾代码，代码尽量精简，不包含#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up
所有变更均有原因及合理的，并且不会影响到其他软件组件代码或BSP All modifications are justified and not affect other components or BSP
对难懂代码均提供对应的注释 I've commented appropriately where code is tricky
代码是高质量的 Code in this PR is of high quality
已经使用formatting 等源码格式化工具确保格式符合RT-Thread代码规范 This PR complies with RT-Thread code specification
如果是新增bsp, 已经添加ci检查到.github/workflows/bsp_buildings.yml 详细请参考链接BSP自查

Rbb666 · 2024-12-26T10:10:16Z

components/drivers/ipc/workqueue.c

    /* remove list */
    rt_list_remove(&(work->list));
-    work->flags &= ~RT_WORK_STATE_PENDING;
+    work->flags = 0;

    if (ticks == 0)
    {
        rt_list_insert_after(queue->work_list.prev, &(work->list));


我觉得这里缺少种情况的判断：比如创建一个工作队列，队列执行后再向其提交一次，正常来说第二次应该返回BUSY了
这块我看之前是有判断的，建议作者添加上：b065486#diff-b63048f1ad2089c43aeb589d9f396dfea3e95b253a0e9c7d13f785bc0613cb31L105

b065486#diff-b63048f1ad2089c43aeb589d9f396dfea3e95b253a0e9c7d13f785bc0613cb31L93-R354
1、看了下上面 b065486 ，这次提交不是去掉BUSY判断用的吗？和我的思路不冲突啊。
2、并且我认为去掉 busy是个明智之举。因为他可以在自己的回调里面再次触发自己，这个是很常用的（至少我很常用，我自己的项目里面大量的使用了回调函数里面再次触发同一个 work的逻辑）。
3、正在触发回调的work， b065486 和我的思路是一样的，都是运行再次添加。
4、实际上我为了处理这个问题，在线程回调的地方，把回调函数在临界区保存为临时变量了(work_func 和 work_data)。退出临界区之后实际上 work 结构体已经是安全的了。f0415bb?diff=split&w=0#diff-b63048f1ad2089c43aeb589d9f396dfea3e95b253a0e9c7d13f785bc0613cb31R96-R109

我没描述清楚，假设这样的条件：工作队列线程回调还没执行完成再次发生了调度，然后在其他线程又向队列提交了一个任务，那么这个时候队列应该处于BUSY吧。

static void work_test_fun(struct rt_work *work, void *work_data) { ...... rt_thread_delay(10); ...... } static void repeat_work_test02(void) { /* 比当前测试线程优先级高 1 */ curr_priority = get_test_thread_priority(-1); queue = rt_workqueue_create("test", 2048, curr_priority); rt_work_init(&work, work_test_fun, (void *)&work_flag); /* 提交任务，队列优先级高，会立即执行 */ rt_workqueue_submit_work(queue, &work, 0); /* 延时让出 CPU */ rt_thread_delay(5); /* 再次提交正在执行的任务，应该返回 BUSY */ err = rt_workqueue_submit_work(queue, &work, 0); ...... }

1、现在需要明确的是：在我这个PR之前，BUSY判断就已经去掉了。我只是沿用他的去掉，我为啥要给他加回去那？
2、你第一条回复的那个提交 b065486 就是去掉 BUSY判断的啊。理由是work正在执行，这时候发生中断，这个中断调用rt_workqueue_submit_work，导致work丢掉。你为啥要用一和你观点完全想法的提交 b065486 来证明你的观点那？我又确认了一遍 b065486 ，好像不是我理解错了把？

3、同时说一下我认为去掉BUSY合理的原因如下（个人观点）：

static void work_test_fun(struct rt_work *work, void *work_data) { // 回调里面直接再次触发自己，如果存在BUSY状态这个会触发失败 // 至于为什么不用循环直接执行，我理解是是要利用 work的先进先出，进行排队执行（都是0延迟的时候），给其他任务执行的空间 // 我个人在项目中使用这种方式驱动了一个主逻辑 rt_workqueue_submit_work(queue, &work, 0); } static void repeat_work_test02(void) { rt_work_init(&work, work_test_fun, NULL); rt_workqueue_submit_work(queue, &work, 0); }

Rbb666 · 2024-12-30T10:23:29Z

components/drivers/ipc/workqueue.c

-        work->flags |= RT_WORK_STATE_PENDING;
-        work->workqueue = queue;
+        work->flags     |= RT_WORK_STATE_PENDING;
+        work->workqueue  = queue;



我意思是不是在这里加个busy的返回判断就行了，因为我看到rt_workqueue_submit_work API返回值就是存在RT_EBUSY状态的：#L317

err = queue->work_current != work ? RT_EOK : -RT_EBUSY;

这个判断，在我这次PR之前就去掉了，已经不判断 BUSY了。BUSY状态下会返回成功，回调执行完成之后会立即重新触发。
去掉BUSY的PR不是我提交的，在 b065486 里面提交的。

我找到了具体PR在 #6932 理由在这个PR里面有写。使用work代理中断，回调没执行完成，中断再次到来会丢中断。

我把注释更新下去掉 BUSY 返回值的注释。

Rbb666 · 2024-12-31T03:54:23Z

我提交了一份有关工作队列的PR ，@yuqingli05 大佬可以看看：#9850

mysterywolf · 2025-01-02T02:50:51Z

我重新出发一下CI

yuqingli05 added 2 commits December 21, 2024 16:28

[ipc/workqueue.c] delete timer, using list.

f0415bb

[ipc/workqueue.c] 删除无用的判断

b96853c

github-actions bot added Component component: drivers/ipc component: drivers labels Dec 24, 2024

yuqingli05 changed the title ~~Pr workqueue~~ workqueue 去掉timer，使用list排序处理方式 Dec 24, 2024

Merge branch 'RT-Thread:master' into pr-workqueue

2607374

Rbb666 reviewed Dec 26, 2024

View reviewed changes

Rbb666 reviewed Dec 30, 2024

View reviewed changes

删除 RT_EBUSY 返回值注释

663d02b

Rbb666 approved these changes Jan 1, 2025

View reviewed changes

mysterywolf closed this Jan 2, 2025

mysterywolf reopened this Jan 2, 2025

Rbb666 merged commit 73ea6da into RT-Thread:master Jan 2, 2025
89 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

workqueue 去掉timer，使用list排序处理方式 #9825

workqueue 去掉timer，使用list排序处理方式 #9825

yuqingli05 commented Dec 24, 2024 •

edited by Rbb666

Loading

Rbb666 Dec 26, 2024

yuqingli05 Dec 26, 2024 •

edited

Loading

Rbb666 Dec 26, 2024 •

edited

Loading

yuqingli05 Dec 27, 2024 •

edited

Loading

Rbb666 Dec 30, 2024

yuqingli05 Dec 30, 2024 •

edited

Loading

Rbb666 commented Dec 31, 2024 •

edited

Loading

mysterywolf commented Jan 2, 2025

workqueue 去掉timer，使用list排序处理方式 #9825

workqueue 去掉timer，使用list排序处理方式 #9825

Conversation

yuqingli05 commented Dec 24, 2024 • edited by Rbb666 Loading

拉取/合并请求描述：(PR description)

为什么提交这份PR (why to submit this PR)

你的解决方案是什么 (what is your solution)

请提供验证的bsp和config (provide the config and bsp)

当前拉取/合并请求的状态 Intent for your PR

代码质量 Code Quality：

Rbb666 Dec 26, 2024

Choose a reason for hiding this comment

yuqingli05 Dec 26, 2024 • edited Loading

Choose a reason for hiding this comment

Rbb666 Dec 26, 2024 • edited Loading

Choose a reason for hiding this comment

yuqingli05 Dec 27, 2024 • edited Loading

Choose a reason for hiding this comment

Rbb666 Dec 30, 2024

Choose a reason for hiding this comment

yuqingli05 Dec 30, 2024 • edited Loading

Choose a reason for hiding this comment

Rbb666 commented Dec 31, 2024 • edited Loading

mysterywolf commented Jan 2, 2025

yuqingli05 commented Dec 24, 2024 •

edited by Rbb666

Loading

yuqingli05 Dec 26, 2024 •

edited

Loading

Rbb666 Dec 26, 2024 •

edited

Loading

yuqingli05 Dec 27, 2024 •

edited

Loading

yuqingli05 Dec 30, 2024 •

edited

Loading

Rbb666 commented Dec 31, 2024 •

edited

Loading