当前位置：文江博客话题详情

是否有东西可以替换功能？

发布于 2024-10-05 01:32:51 字数 220 浏览 4 评论 0原文

中的用户线程函数已被弃用，因为它们使用了已弃用的 C 功能（它们使用带空括号的函数声明作为参数）。

有标准的替代品吗？我不认为成熟的线程擅长实现协作线程。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

笑看君怀她人 2024-10-12 01:32:52

如果您确实想做 ucontext.h 函数允许的事情，我会继续使用它们。其他任何东西都会不太便携。在 POSIX 中将它们标记为过时似乎是委员会中某人犯下的一个可怕的迂腐错误。 POSIX 本身要求函数指针和数据指针具有相同的大小，并且函数指针可表示为 void *，而 C 本身则需要在函数指针类型之间进行强制转换以实现往返安全，所以有很多方法可以解决这个问题。

有一个真正的问题，如果没有编译器的大力帮助，则无法将传递到 makecontext 的 int argc, ... 转换为传递给函数的形式，除非可变参数和非可变参数函数的调用约定恰好是相同的（即使如此，是否可以稳健地完成还是相当值得怀疑的）。不过，这个问题本来可以通过不赞成以 makecontext(ucp, func, 1, (void *)arg); 以外的任何形式使用 makecontext 来解决。

也许更好的问题是为什么您认为 ucontext.h 函数是处理线程的最佳方法。如果您确实想使用它们，我可能建议编写一个包装器接口，您可以使用 ucontext.h 实现或使用 pthreads 实现，然后比较性能和膨胀。这还有一个优点，如果未来的系统放弃对 ucontext.h 的支持，您可以简单地切换到使用基于 pthread 的实现进行编译，一切都会简单地工作。（到那时，膨胀可能不再那么重要，多核/SMP 的好处可能会很大，并且希望 pthread 实现不会那么臃肿。）

编辑（根据 OP 的请求）：使用 pthread 实现“协作线程”，需要条件变量。这是一个不错的 pthreads 教程，其中包含有关使用它们的信息：

https://computing.llnl.gov/tutorials/pthreads/#ConditionVariables

你的协作多任务处理原语“将执行移交给线程 X”会像这样：

self->flag = 0;
other_thread->flag = 1;
pthread_mutex_lock(other_thread->mutex);
pthread_cond_signal(other_thread->cond);
pthread_mutex_unlock(other_thread->mutex);
pthread_mutex_lock(self->mutex);
while (!self->flag)
    pthread_cond_wait(self->cond, self->mutex);
pthread_mutex_unlock(self->mutex);

希望我没问题；至少总体思路是正确的。如果有人看到错误请评论，以便我修复。对于这种用法，一半的锁定（other_thread 的互斥体）可能是完全不必要的，因此您也许可以将互斥体设置为 task_switch 函数中的局部变量。您真正要做的就是使用 pthread_cond_wait 和 pthread_cond_signal 作为“进入睡眠”和“唤醒其他线程”原语。

If you really want to do something like what the ucontext.h functions allow, I would keep using them. Anything else will be less portable. Marking them obsolescent in POSIX seems to have been a horrible mistake of pedantry by someone on the committee. POSIX itself requires function pointers and data pointers to be the same size and for function pointers to be representable cast to void *, and C itself requires a cast between function pointer types and back to be round-trip safe, so there are many ways this issue could have been solved.

There is one real problem, that converting the int argc, ... passed into makecontext into a form to pass to the function cannot be done without major assistance from the compiler unless the calling convention for variadic and non-variadic functions happens to be the same (and even then it's rather questionable whether it can be done robustly). This problem however could have been solved simply by deprecating the use of makecontext in any form other than makecontext(ucp, func, 1, (void *)arg);.

Perhaps a better question though is why you think ucontext.h functions are the best way to handle threading. If you do want to go with them, I might suggest writing a wrapper interface that you can implement either with ucontext.h or with pthreads, then comparing the performance and bloat. This will also have the advantage that, should future systems drop support for ucontext.h, you can simply switch to compiling with the pthread-based implementation and everything will simply work. (By then, the bloat might be less important, the benefit of multi-core/SMP will probably be huge, and hopefully pthread implementations will be less bloated.)

Edit (based on OP's request): To implement "cooperative threading" with pthreads, you need condition variables. Here's a decent pthreads tutorial with information on using them:

https://computing.llnl.gov/tutorials/pthreads/#ConditionVariables

Your cooperative multitasking primitive of "hand off execution to thread X" would go something like:

self->flag = 0;
other_thread->flag = 1;
pthread_mutex_lock(other_thread->mutex);
pthread_cond_signal(other_thread->cond);
pthread_mutex_unlock(other_thread->mutex);
pthread_mutex_lock(self->mutex);
while (!self->flag)
    pthread_cond_wait(self->cond, self->mutex);
pthread_mutex_unlock(self->mutex);

Hope I got that all right; at least the general idea is correct. If anyone sees mistakes please comment so I can fix it. Half of the locking (other_thread's mutex) is probably entirely unnecessary with this sort of usage, so you could perhaps make the mutex a local variable in the task_switch function. All you'd really be doing is using pthread_cond_wait and pthread_cond_signal as "go to sleep" and "wake up other thread" primitives.

回复收藏 0 原文