y****n
发帖数: 192 | 1 一个线程在读文件的时候会不会把文件锁住？
另外，是不是即使用多线程同时读文件也不会加快速度呢？我的理解是I/O通道只有一个，单线程和多线程能达到的速度已经被瓶颈了。
谢谢！ |
|
z****e
发帖数: 2024 | 2 我靠，我一天不来，就乱成这样了？？？
还没来得及看全回帖。
1. mutex 就够了。mutex就是干lz说的这个情况用的。
2. C++根本就是单线程模式，其多线程依赖于具体的library。C++0x已经在标准里边加
了多线程，std::thread. gcc 4.4以上可用，windows下用just::thread,这个是C++的
未来。其他的库都不是标准支持的，而多线程从理论上说，是不能用库来实现的。有大
牛的一篇文章讲这个。 |
|
z****e
发帖数: 54598 | 3 我压根没谈线程和进程
我的意思是，不管是线程还是进程
你都不需要自己动手去做
多线程也好，多进程也罢
无非一个调度的问题
自己折腾说到底就是自己处理调度
跟level有个p关系
说的根本就不是区别，而是共同点
看一群人大谈差异，让我觉得好笑
kernel |
|
j*****u
发帖数: 1133 | 4 因为多线程同时读，文件在同一块物理硬盘上，磁头要来回切换磁道
文件读取受限于硬盘，多线程不会提高速度 |
|
c*****t
发帖数: 1879 | 5 如果你的文件很大，同时处理的时间很长。双线程其实是个不错的选择。
一个专门读硬盘（producer），一个专门处理（consumer）。即使只有
一个 cpu，也是很好的选择。
一般的
while ( read ( buffer ) )
{ dealwith ( buffer ); }
有个很大的问题就是，没有利用 I/O block 的时候（其实 cpu idle）
做事情。不过一般文件小，又因为 disk cache，效果不是太明显。大
文件就比较重要了。
一个，单线程和多线程能达到的速度已经被瓶颈了。 |
|
x****u
发帖数: 44466 | 6 这个仅仅在gcc的非线程安全的优化模式下才有意义。
现在几乎没有这样的程序非要单线程的极端优化，MSVC也是默认不破坏多线程语义。 |
|
A*****i
发帖数: 3587 | 7 别闹了行么？该干啥去干啥，一个多线程让您吹成绿卡神器了
还扯上大脑结构了，卧槽，吐槽无力
您大脑结构是万线程的，满意了？ |
|
z****e
发帖数: 54598 | 8 应该说fp不反对var
反对var是为了多线程编造出来的谎言
因为pure fp解决不了多线程带来的var冲突
所以只好immutable鸟
这完全没有必要，就跟单线程一样
纯粹浪费 |
|
z****e
发帖数: 54598 | 9 应该说fp不反对var
反对var是为了多线程编造出来的谎言
因为pure fp解决不了多线程带来的var冲突
所以只好immutable鸟
这完全没有必要，就跟单线程一样
纯粹浪费 |
|
L*****e
发帖数: 8347 | 10 单就抢票这个功能来讲，我一开始就以为你的方案就是单核，并且我也建议单核。你的
方案多核多线程对performance提高有限，极端情况甚至会降低，并且增加了很多不稳
定性。。。 |
|
e***a
发帖数: 1661 | 11 多线程算法 比 刷题网站上的单线程算法 难很多。
想请教 应该看哪几本书？ |
|
a****l
发帖数: 8211 | 12 Not only will multi-threading not increase the reading speed of a file, most
probably it would actually slow down the speed and at the same time is
murdering the hard drive. Good luck.
一个，单线程和多线程能达到的速度已经被瓶颈了。 |
|
r******r
发帖数: 700 | 13 是啊。多线程程序，试了一下，在 eclipse 里 debug，好像也与单线程不一样，不太
好 track 逻辑。 |
|
l*****o
发帖数: 473 | 14 我试着对楼主的方法进行点评一下，好像还有许多地方是可以提高的。
《《（1）将原来的逐行读取，逐行处理，改为先将每个文件的所有行读到一个新建的
DataStore 中。
这步是可以用memory mapped file进行提高的。如果单线程读取所有的文件，那么这部
分工作就变成串行化了。
《《（4）现在由于多线程异步处理，直接输出无法保证顺序。就先把这部分信息存储
到一个新建的 map 中，保存记录 ID -> data 的映射。当一个文件处理完了，才最后
按 ID 从map 有序输出到 XML 中。
为了保证顺序，其实还有其它方式可以处理的。比如，我们可以输出到不同文件中，最
后用脚本把所有东西重新拼成一个新的文件。 |
|
M********u
发帖数: 42 | 15 如果是简单的for loop，就用openmp包在loop外。如果logic比较复杂，需要手动
create thread。没有一个简单的办法把一个单线程的程序改成多线程的 |
|
p***o
发帖数: 1252 | 16 单线程语义 is well defined.
There is no such thing called 多线程语义, especially for multiple variables. |
|
z****e
发帖数: 2024 | 17 我怎么觉得很多情况多线程都比单线程慢呢？
我是能不加互斥锁就不加，
而且也没有busy waiting。
看见两个cpu100%工作，结果，还是比一个cpu100%要慢，或者想当。
这种为什么？ |
|
z****e
发帖数: 2024 | 18 我就是单线程用的那个f。
觉得多线程这玩意还真难搞得很精通。 |
|
|
m******t
发帖数: 635 | 20 怎么让我想起了ruby里的Fiber，几年前很热闹过一阵，忘了后来怎么样了。
怎么感觉js一副要重走长征路的样子，要把perl, python, ruby的老路子再重来一遍？
加了多线程的话，js的语义会不会有问题啊，以前一直假设单线程的啊？ |
|
a*********0
发帖数: 2727 | 21 哥们还是回去好好把os的基础知识学学吧，线程进程的区别是什么都没搞清楚，kernel
-level, user-level thread的区别是什么。忽悠不是cs科班出来的还行，现在码工遍
地，就不要出来现了 |
|
z****e
发帖数: 54598 | 22 这种笑话，当真就搞笑了
多线程搞起来是比较恶心
但是市场如果不需要你去搞
那就是另外一回事了 |
|
z****e
发帖数: 54598 | 23 没有哦
你要告诉我os搞不定多线程的调度还是什么？
你这不是吃饱了撑着嘛 |
|
H**r
发帖数: 10015 | 24 说得好
程序员应该知道多线程是什么，然后用什么工具解决。具体的算法，优化如果都从头走
要累死，而且肯定会有疏忽，然后就挂了。 |
|
z****e
发帖数: 54598 | 25 多线程的话，一起刷新主界面？
会闪，我看android还是一个主线程在跑 |
|
s****u
发帖数: 1433 | 26 某些地方想简单了是可以修改的。
我就是想提示一下，连订票人都不区分，怎么个订法？
比如10个人买8张票，我肯定知道前8个有票，后
两个没票。问题是卖给谁了啊？
所以，每个ReserveTicket的子线程肯定得有个标识吧。
抢完票以后，ReserveTicket以后，肯定得把
这个结果根据子线程的标识把这个结果记录进数据库吧。
然后，还得通知顾客抢票成功或者失败吧。
产生这些通知的程序在哪里呢？
这些不靠这个CPU同时干么？
这些问题，魏老师打算怎么解决啊？ |
|
e***a
发帖数: 1661 | 27 多线程算法 比 刷题网站上的单线程算法 难很多。
想请教 应该看哪几本书？ |
|
z****e
发帖数: 54598 | 28 fp涵盖了var
只是不推荐使用var
否则会在并发的时候用上大量的lock
会让你的程序变得难以维护
这一点上说，无论什么多线程的框架
其本意都是为了让用户不再使用lock
像单线程一样编程是目的
这个其实无论啥都是一样的
但是实现的手段截然不同，而且效果也很明显有差异 |
|
z****e
发帖数: 54598 | 29 fp涵盖了var
只是不推荐使用var
否则会在并发的时候用上大量的lock
会让你的程序变得难以维护
这一点上说，无论什么多线程的框架
其本意都是为了让用户不再使用lock
像单线程一样编程是目的
这个其实无论啥都是一样的
但是实现的手段截然不同，而且效果也很明显有差异 |
|
|
发帖数: 1 | 31 下面是单线程，而且图是adjacency list
public class Solution {
//5763 ms, method: bfs, 时间O(N + E)，空间O(N)。
public List> connectedSet(ArrayList
nodes) {
List> res = new ArrayList<>();
List path = new ArrayList<>();
Set visited = new HashSet<>();
for (UndirectedGraphNode node : nodes) {
if (!visited.contains(node)) {
path.clear();
Queue阅读全帖 |
|
|
|
h**********c
发帖数: 4120 | 34 \\单线程程序
#include
#include
#include
#include
#include
void parsePermutation (int n, int m, int * rindx,int *results) {
int * data = new int[n];
int i =0,j=0;
for (i=0; i
data[i] = i+1;
for (i=0; i
results[i] = data[rindx[i]-1];
for (j=rindx[i]-1; j
data[j] = data[j+1];
}
}
delete [] data; data = NULL;
}
bool getXs(int n,int *inputs, int * rs) {
bool |
|
h**********c
发帖数: 4120 | 35 在单线程程序的for 前面加了一句,
#pragma omp parallel for
performance 略有提高,285.905950秒,
1. 无法证实performance提高了,还是今天晚上运行的程序少了,monitor上显示,一个核
负载比较大,其他的核少,比较均匀.
2. 没有实现cs or mutex,#pragma omp parallel for估计不能处理race condition(有
待查证). |
|
c*m
发帖数: 1114 | 36 我觉得你应该去google一下，关掉HT占cpu 25%不见得比不关HT 占cpu 13%就快。单线程
cpu的计算能力应该是一定的，即使会比关HT的差点也不会差很多，否则提出HT这个概
念就是个joke. 25%和13%这些数值不能说明任何问题。 |
|
z****e
发帖数: 54598 | 37 只要避开并发操作，都不难
实际上单线程和异步也是用来规避并发用的 |
|
x****u
发帖数: 44466 | 38 你得有根据。
如果global variable被编译器优化成了两个不相干的值，那么这就直接违反了其定义
，必须在every scope里面accessible。
C语言里面从没有说这句话有个单线程的前提，所以还是可以被报告bug。
not |
|
x****u
发帖数: 44466 | 39 我手头没有gcc的环境，msvc的行为和我预测一致。
另外我能查到的所有文档都没有说global variable仅仅在单线程时是global的，质疑
标准的其实是你。
you |
|
t****t
发帖数: 6806 | 40 我早跟你说了没什么可研究的, 这个是well defined behaviour and well known, C/C
++本来就是单线程模型, 你非要当个大发现还硬说是bug. 同步本来就应该靠intrinsic
, 或者一定要lock-free的话, 用atomic. volatile就是在没有atomic的情况下一个临
时的代替品, 自己也不是很靠谱的, 何况还有CPU在那里搞乱序. |
|
z****e
发帖数: 2024 | 41 刚才编译有个typo，后来发现了，-O3是总体快了很多。但是仍然是单线程快
output |
|
|
g*****g
发帖数: 34805 | 43 你写过吗？有多少同时在线用户？纯扯蛋。除非你用node之类单线程的架构，否则是不
可避免的。 |
|
|
T********i
发帖数: 2416 | 45 你的这个理解正确。
其实我也是纸上谈兵，写了几行比划一下。先选多线程带lock指令的。
这里赞一下SSA的contention解决方案，确实elegant。
后来我感觉多核的代价也挺高，就试验了一下这个单核，简单，一致，而且性能超高。
发现 |
|
|
z****e
发帖数: 54598 | 47 其他框架根本不需要多process，去哪里来的ipc问题？
node的ipc放在其他框架就是itc，而且vert.x天生就有一个bus予以解决
node还要自己倒腾第三方工具予以解决，只有node需要倒腾第三方工具解决并发问题
其他都不用，哪怕是akka都是自己搞定，所谓ipc就是一个集成的问题
单机系统还需要集成的只有单线程，其他都不用，自己能搞定
这个完全是一个名词上的混淆，根本不是什么优势，是大大滴劣势
至于io快，纯粹胡说八道，vert.x vs node.js的报告到处都是
自己试试就知道node有多烂了，你还是没试过，凭想象来指责其他框架的问题 |
|
|
z****e
发帖数: 54598 | 49 其他框架根本不需要多process，去哪里来的ipc问题？
node的ipc放在其他框架就是itc，而且vert.x天生就有一个bus予以解决
node还要自己倒腾第三方工具予以解决，只有node需要倒腾第三方工具解决并发问题
其他都不用，哪怕是akka都是自己搞定，所谓ipc就是一个集成的问题
单机系统还需要集成的只有单线程，其他都不用，自己能搞定
这个完全是一个名词上的混淆，根本不是什么优势，是大大滴劣势
至于io快，纯粹胡说八道，vert.x vs node.js的报告到处都是
自己试试就知道node有多烂了，你还是没试过，凭想象来指责其他框架的问题 |
|
