h**********c
发帖数: 4120 | 1 I review the post.
It seems you probably can't do this, cause the underling thread library for
MingW/cygwin etc is pthread. MSVC uses thread library Microsoft wrote.
So in your Ming code and MSVC, do they include the same boost library. |
|
b********e
发帖数: 58 | 2 Or you can try boost:thread, which is cross platform. |
|
y****e
发帖数: 23939 | 3 编译的时候需要额外的头文件吗？运行的时候需要什么windows和VC以外的库文件吗？ |
|
p********n
发帖数: 1707 | 4 window 7 has its own multi-threads library.Very easy to use. |
|
EM
发帖数: 715 | 5 native thread阿，不是pthread... |
|
r*********r
发帖数: 3195 | 6 c++ 有什么native threads?
libstdc++ 多半是用 pthread 写的。 |
|
A******g
发帖数: 612 | 7 MPI,OpenMP,Pthread,CUDA有点了解吧 |
|
j*****I
发帖数: 2626 | 8 以上除了pthread,敢问您是真的在用，还是研究研究? 恕孤陋寡闻哈 |
|
m******t
发帖数: 4077 | 9 和pthread library里面的sem_init() 有啥区别和关系？
sema vs sem... |
|
t****t
发帖数: 6806 | 10 更好的interface是指c++11吗? 那其实还是调用pthread的.
这本书就是选了一些posix api讲了讲而已, 其实意义不大. 当然如果完全没接触过,
还是可以入门看一看. |
|
n******t
发帖数: 4406 | 11 所有的这种"肆无忌惮的xxx"，都是有问题的。。。
肆无忌惮的create pthread,肆无忌惮的create connection,肆无忌惮的open files,
就算Java本身不一定效率低，就单单从it鼓励程序员这么干这一点来说，就不是一个
高效的语言。
而且现在要管理的resource多了去了，GC只是memory而已，要一劳永逸不是那么简单的。 |
|
s********k
发帖数: 6180 | 12 python有GIL的问题，不过Python3.0以上已经解决了这个问题，再说python还有
multiprocess的支持。说实话，用到multithreading的地方真不适合python，底层直接
用pthread就好了。如果做Application的并发，multithreading本来就不算一个很好的
选项，python这么多好的库，比如twisted之类的event based，或者直接用yield做
corouting，比起多线程都要好得多
ruby |
|
s********k
发帖数: 6180 | 13 我不熟悉node.js,不比较了。据说linkedin用它直接可以把10台服务器做的事情压缩到
一台，也很牛逼，不过我觉得不只是语言牛逼，而是处理问题方法变了。应该说event
based的处理代替multithreading在Application层面算是大势所趋吧。这个我觉得跟语
言无关，高性能web 服务即便C也是epoll之类的比pthread用的多了。python有twisted
的这样的库支持。node.js好像全是event driven的。二爷你熟悉的scala不是也不是
multithreading的吗？ |
|
s********k
发帖数: 6180 | 14 python使用thread已经out了，好的架构都是用event based，python针对的应用大部分
并不需要intensive的threading，否则要拿pthread直接写还好点。
不过thread safe确实程序员需要了解，OS的基本功之一 |
|
c***d
发帖数: 996 | 15 这个说法比较糊涂啊。 async 在 user space上原本就两种实现， 一个是基于轻量
mutex出来的pthread， 一个是基于epoll/kqueue封装出来的libevent. 你可以说async
不等于性能， 但说async不等于concurrency, 这个需要一些超过普遍认知的定义。
c1- |
|
s*w
发帖数: 729 | 16 又琢磨了两天，看了不少相关东西，终于搞定了，觉得自己对这个多线程的理解加强了
很多。思考比单纯的看人说原理更刻骨铭心。
这个问题我设计的用一个 producer 多个 consumer 的架构，上个版本的是两头用
condition_variable, 一个通知 producer 有空间了开始干活生产，另一个通知
consumer 有库存了开始消费。参见上篇里面的 wait 和 notify_all,notify_one 语
句。 这个思路对于单 producer 单 consumer 没问题，可是不适用于 多 consumer.
因为所有的 consumer 可能同时睡觉（没空存），同时醒来（有库存）,结果只有一个
能抢占mutex(拿到库存)，其他的只好继续睡觉（while 循环 wait）. 如果无限制的
生产下去，每个睡觉的都有机会醒来干活。可是在有限生产的情况下，producer 干完
活了后，总有睡觉的 consumer 无人唤醒导致死锁。解决的办法就是用 non-block
的 try_lock, lock 不上就返回 false，这样有机会检查是否需要(还在生产或是有
... 阅读全帖 |
|
d****i
发帖数: 4809 | 17 多线程远早于OO, UNIX下的pthread早就有了。FP就是用来意淫写写上层的东西，但是
即使这样FP也不是必须的，淘宝那么大的流量用Java没问题。底层的东西还得C来写，
以前80年代有过一阵子lisp machine研究，后来被证明是个joke, 全部死菜菜了。 |
|
T********i
发帖数: 2416 | 18 #if defined(_MSC_VER)
# pragma once
#include
inline long long InterlockedIncrement(long long volatile *ptr) {
return InterlockedIncrement64(ptr);
}
inline long long InterlockedDecrement(long long volatile *ptr) {
return InterlockedDecrement64(ptr);
}
#else
#include
template
inline T InterlockedIncrement(T volatile *ptr) {
return __sync_add_and_fetch(ptr, 1);
}
template
inline T InterlockedDecrement(T volatile *ptr) {
return __sync... 阅读全帖 |
|
w***g
发帖数: 5958 | 19 C++11的并发性支持后面是pthread, 虽然马甲看起来差不多，但怕是经不起高并发的任
务。有人benchmark过吗？ |
|
d****i
发帖数: 4809 | 20 这个不对吧，应该是C才是王道，Java和C++的concurrency底层的实现都是靠OS层的进
程线程这些东西，实际上就是pthread和Win32 thread这些东西来实现的。 |
|
p***o
发帖数: 1252 | 21 裸用pthread跟汇编有一拼, 多核还是得上TBB之类。 |
|
z****s
发帖数: 192 | 22
cannot
我非高人。但知道你的编译器好像没找到 pthread library 的路径。修改环境变量“
LD_LIBRARY_PATH”再试一试。 |
|
g*********e
发帖数: 14401 | 23 用新的库也不麻烦
pthread之类确实要考虑的多 |
|
|
W***o
发帖数: 6519 | 25 曾经，折腾pthread, pre-emptive threads scheduling 折腾的我头疼， node
callback 感觉没有那么抽象，觉得要容易一些 |
|
d*******r
发帖数: 3299 | 26 1，2 楼的大概意思是，用 JS callback 的抽象来写并发执行的程序，比用 pthread
之类的抽象来写，要简单很多了。 |
|
f********s
发帖数: 526 | 27 我装了一下装不上, ./configure没问题, 但是接下来用make的时候, 系统提示这个错
误, 大牛给看看, 咋办啊? 多谢啦~
.....
copying and adjusting /home/yanwang/.local/share/Trash/files/Python-3.4.1/
Tools/scripts/2to3 -> build/scripts-3.4
copying and adjusting /home/yanwang/.local/share/Trash/files/Python-3.4.1/
Tools/scripts/pyvenv -> build/scripts-3.4
changing mode of build/scripts-3.4/pydoc3 from 664 to 775
changing mode of build/scripts-3.4/idle3 from 664 to 775
changing mode of build/scripts-3.4/2to3 from 664 to 775
changing mode of build... 阅读全帖 |
|
d****i
发帖数: 4809 | 28 C++ std::thread or boost::thread just wraps the underlying OS thread on
Win32 thread (Windows) and pthread (Linux), respectively. So it's still OS
dependent under the hood. |
|
g*********e
发帖数: 14401 | 29
#ifdef WIN
windows thread
#else
linux thread
#endif
不过pthread的api应该都可以通吃 |
|
|
d****i
发帖数: 4809 | 31 当然有pthread，这个是UNIX和Linux的重要组成部分之一啊，只不过以前很多东西在不
同的UNIX下面由于实现不同，加上接口函数的名字又不同，后来Open Group和Single
UNIX Specification把他们逐步标准化和统一接口了。 |
|
w***g
发帖数: 5958 | 32 C++没啥好的轻量级线程库。C++11连pthreads，建上几万个线程
就出错了。比go, scala啥的都差大老远了。
python做科学计算也就是做个流程，真正的活都是fortran，C/C++代码,
都已经并行化了的。 |
|
w***g
发帖数: 5958 | 33 gcc的openmp是shared memory，机制跟natureOK的差不多，就是语法更好，各种控制更
多。
比如要把vector jobs里的每个东西用work函数算一个结果出来放入vector<
Result>里，并且要打印progress，用下面的代码就行
#include
boost::progress_display progress(jobs.size(), cerr);
result.resize(jobs.size());
#pragma omp parallel for
for (unsigned i = 0; i < jobs.size(); ++i) {
work(jobs[i], &results[i]);
#pragma omp critical
++progress;
}
openmp可以通过编译器命令行启动或者禁止。禁止的话就是传统的单线程程序。
用C（包括C with class)写才直接用pthread。就是C++11之前也早就有boost::thread
了。 |
|
S*A
发帖数: 7142 | 34 不必要的复杂。你自己写的不是很觉得，你要从完全没有
读过你代码的人角度看。楼上那个openmp 的代码就精简
很多。
而且你名字类似，功能细微区别的函数太多。反正回到
基本点上，用 pthread 直接实现一个代码篇幅都要比你
得小。而且看的清楚 thread 都是那里来的哪里结束的。
或者你的这个例子不成功，另外有其他的妙用你没有展示
出来。我觉得看到的是不必要的中间层。 |
|
w***x
发帖数: 105 | 35 个人觉得先学点基本知识，比如pthread的各个api要弄明白，然后看看相关的linux
kernel代码，具体到某个cpu架构下如何实现，然后看cpu spec弄懂具体怎么回事，接
着可以看看lock free的一些实现。到此可以说真正明白了多线程编程是怎么回事。有
了这些基础知识，理解更高阶的算法或者coding实现一些多线程的应用，就会得心应手
了。 |
|
d****i
发帖数: 4809 | 36 My feeling is the reverse: JavaScript is much more difficult than Java. Java
's multitheading is not that hard, if you know the basic fundamentals of
pthread in Linux, it is somewhat very close in philosophy, just a higher
level wrapper.
function |
|
p***o
发帖数: 1252 | 37 估计是自己实现的同步逻辑。这个需求用pthread barrier就好。
flag |
|
s******u
发帖数: 501 | 38 什么意思？process启动之后本身就是一个main thread，你说的是thread#1和main
thread之间做sync么？这样子当然可以 |
|
k****y
发帖数: 781 | 39 Thread #1 和main thread 做sync.
Thread #1 和process都要access 同一个slow peripheral hardware, 我想吧大量硬件
处理部分移到thread, 目的就是不想block main thread. Main thread 里面也需要经
常access 这个hardware. |
|
s******u
发帖数: 501 | 40 可以，这个没问题，就把main thread当成普通的一个thread，直接用mutex.lock/
unlock就可以了 |
|
g*********e
发帖数: 14401 | 41 youneed to use ipc technics like shared memory and socket
Synchronization can be done with semaphore |
|
w***g
发帖数: 5958 | 42 因为是网络服务，还要从数据库读东西，中间延时比较多。
每个请求真正的CPU时间往往远不足1ms。所以需要多线程。
楼上说java也有道理。不过我这个应用如果用java实现，
再多5倍机器都不够。我这个问题在java里可能就成为正常情况了，
反正是多耗内存的事情。有人能确认jvm没有用pthread和malloc吗？
C++是我的job security。 |
|
w***g
发帖数: 5958 | 43 pthread是包在OS线程外的。light-weighted thread需要用到用户态线程。
微软的fiber是用户态的，但是因为是windows世界的，不怎么招人待见。
在多核上做用户态线程是一件非常非常恶心的事情，GO最主要的贡献其实
就是把这件事做成了。主要的恶心之处就是怎么处理job stealing:一个
操统线程上面的任务都跑完了，就需要去别的操统线程那儿把活弄过来。
这就涉及到各种同步，各种locking。Locking多了，性能就下来了。
这种事情以前应该不少公司内部都有人做过，能做这个的人一般也都
屌得不得了。其实稍微对比一下就能知道multi-core有多难做：
node.js不支持multi-core，python折腾这么多年也还是个残疾。
如果你想更多地了解一下，可以从man makecontext
看起。每个用户态线程其实是一个context。然后底下每个操统线程负责
管一堆context。context切换主要靠cooperative scheduling，而不是操统
用的preemptive scheduling。也就是说一个context运行到某一步... 阅读全帖 |
|
d****i
发帖数: 4809 | 44 大牛高，赞详解。我做了那么多年，不管是当年的Solaris, 还是现在的Linux，还是那
些众多的RTOS, 清一色的preemptive。pthread确切的说应该是user space created的
thread，但是under the hood由kernel thread来support的吧， |
|
w***g
发帖数: 5958 | 45 我有段时间老搞不明白plan 9有啥牛B的。后来才发现plan 9提出的不少新概念已经被
Linux借鉴了。Plan 9是80年代的东西，Linux是90年代的东西。我知道plan 9是2005
年，自然是见怪不怪了。话说我当年在的实验室有个plan9的拥趸，说起来就是
"pthread is broken"。当时我们做的project底层是一套不知道从哪儿搞来的
用户态plan9的库。
就像现在读阿西莫夫的小说，自然读不出任何新鲜的东西。
thread |
|
d****i
发帖数: 4809 | 46 你扯啥，Java就是C和C++的正宗嫡传和马甲，Java的多线程完全是wrap的pthread和
Win32 thread, 完全一样。 |
|
k******n
发帖数: 184 | 47
不用做测试了，无论是在自己的操作系统还是用multi2sim模拟都不成立。
当年我在 multi-core CPU arch&programming 课上就做过这种junior level research
report, java的多线程和c++ pthread都写过。从1个core到8个core， 每个core从1-4
个线程， 从基本的unix指令到scientific computing算法都测试过。 |
|
d****i
发帖数: 4809 | 48 来自主题: Programming版 - 代码开源了 #include
static pthread_t createThreadStd(
QWThreadStartRoutine startRoutine,
void *arg)
赞 |
|
g****u
发帖数: 252 | 49 我看了mTCP的paper。这货的目的是要代替内核TCP。threading model和别的一系列
design decision都是按这个目的做出的。作为一个用户态的通用的TCP库，需要实现
两点：
- 库本身不能霸占着CPU不放。因为用户程序可能也要跑CPU。所以mTCP是基于event
而不是polling的。mTCP本来应该是从PSIO(event)开始做的。DPDK应该是后来加上去的。
DPDK是polling。
- 不能假设逻辑线程<=物理线程。对于有的应用，逻辑线程可能是物理线程的
好几倍，靠send/recv阻塞的时候操统调度来提高硬件利用率。我那个客户端就是
这么干的。
这个paper里提到了context-switch。这是很明显的一个indicator: paper里讲的
线程是逻辑线程。如果限制线程数绑定CPU，mTCP应该可以做成context-switch-free的。
不过得把pthread那套同步机制全都换掉才行。
关键还是通用 vs 专用的问题。如果做成专用的话，paper估计就发不出去了。
其实写paper的时候把PSIO换成DPDK，review... 阅读全帖 |
|
i**p
发帖数: 902 | 50 我也觉得纳闷。一次一个中国女猎头（这真少见，至今才碰到一个）要拉我入她家公司
，抱怨现有的产品出了无数并发问题。第一次可以与猎头用国语讲话，兴奋的过了头，
问她讲为何设计如此之好的JAVA multiple-threading会有如此之多的问题？我们这些
写过pthread再来写JAVA从来没碰到过任何问题。结果这姐说我不懂JAVA。 |
|
