a********d 发帖数: 195 | 1 先问个问题,read-write lock里要实现当lock请求过来之后,让所有reader都read完
然后再去write lock,是不是再加一个mutex还是只check semaphore就行了?(只有一
个写锁,n读锁)。这方面脑子不清楚...
然后是小感一下,进门等候的时候看见氛围不错,路过的人脸上笑容挺不少,后来发现
不是开发部,等到了开发部,就阴沉了很多,大家表情严肃,一些调程序的人的控制台
程序屏幕不停刷着,比较闷。面试的人都很nice,期待这家能有好的回馈。 |
x*******6 发帖数: 262 | |
h*****3 发帖数: 1391 | |
r********g 发帖数: 1351 | 4 如果只read,是不是不用mutex了啊?lz有啥hint不?
【在 a********d 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 先问个问题,read-write lock里要实现当lock请求过来之后,让所有reader都read完 : 然后再去write lock,是不是再加一个mutex还是只check semaphore就行了?(只有一 : 个写锁,n读锁)。这方面脑子不清楚... : 然后是小感一下,进门等候的时候看见氛围不错,路过的人脸上笑容挺不少,后来发现 : 不是开发部,等到了开发部,就阴沉了很多,大家表情严肃,一些调程序的人的控制台 : 程序屏幕不停刷着,比较闷。面试的人都很nice,期待这家能有好的回馈。
|
a********d 发帖数: 195 | 5 这个还真没用过,看了看感觉区别据说是这样:
CountDownLatch是一组线程等待所有的线程都结束或者计数结束。
semaphore控制同时对资源访问的数量。
问题是semaphore上下浮动,如何控制说一个write过来了,控制semaphore数量直到0?
额外的mutex还是啥?迷糊了已经。
【在 x*******6 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我怎么感觉应该用CountDownLatch
|
x*******6 发帖数: 262 | 6 你的意思是当要write的时候,让所有reader停止,然后write?
这个可以把所有的read task放到一个ExecutorService里执行,要write的时候把它
shutdown并且awaitTermination()到所有task执行完。然后再连上writer执行write
。不知道这样对不对。
【在 a********d 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这个还真没用过,看了看感觉区别据说是这样: : CountDownLatch是一组线程等待所有的线程都结束或者计数结束。 : semaphore控制同时对资源访问的数量。 : 问题是semaphore上下浮动,如何控制说一个write过来了,控制semaphore数量直到0? : 额外的mutex还是啥?迷糊了已经。
|
r****s 发帖数: 1025 | 7 扯淡,这就是要你写的时候acuire所有的read lock,就像concurrenthashmap里面的
size。
所有的read进来都要等write待lock。所以write先acuire那个write lock,后面的read
就进不来了,然后再一个一个地acquire那些read lock。
实在看不过去,愤然发帖指正。 |
B*******1 发帖数: 2454 | |
a********d 发帖数: 195 | 9 多谢,就是这个了,之前就不知道那个读的semaphore应该怎么冒到limit,看了发现一
个循环加上去,哎...真是浆糊。
【在 B*******1 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 似乎就是这个吧。 : http://doc.qt.nokia.com/qq/qq11-mutex.html
|
a********d 发帖数: 195 | 10 呵呵,轻喷,学习了。
看了楼下贴的链接,发现好像是没有让read都要等待write lock,而是一个write lock
放mutex,然后开始一个一个收semaphore,收到满然后执行write后semaphore全放掉。
这样省了read去看write lock。不知道理解对不对,望指正。
read
【在 r****s 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 扯淡,这就是要你写的时候acuire所有的read lock,就像concurrenthashmap里面的 : size。 : 所有的read进来都要等write待lock。所以write先acuire那个write lock,后面的read : 就进不来了,然后再一个一个地acquire那些read lock。 : 实在看不过去,愤然发帖指正。
|
|
|
x*******6 发帖数: 262 | |
r****s 发帖数: 1025 | 12
lock
read 不需要看mutex吗?
另外semaphore没有一个一个的说法,semaphore里有permit。
【在 a********d 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 呵呵,轻喷,学习了。 : 看了楼下贴的链接,发现好像是没有让read都要等待write lock,而是一个write lock : 放mutex,然后开始一个一个收semaphore,收到满然后执行write后semaphore全放掉。 : 这样省了read去看write lock。不知道理解对不对,望指正。 : : read
|
a********d 发帖数: 195 | 13 确实,这个实现里面对这个有点宽容,就是write在收semaphore的时候并不保证在全部
收走之前读不会进来,这也算是这个简洁设计的小缺陷,不过应该可以忍。
【在 r****s 的大作中提到】![](/moin_static193/solenoid/img/up.png) : : lock : read 不需要看mutex吗? : 另外semaphore没有一个一个的说法,semaphore里有permit。
|
r****s 发帖数: 1025 | |
a********d 发帖数: 195 | 15 恩,好在收semaphore的循环是不可逆的,eventually会归0,只是没那么快。
多谢解答。
【在 r****s 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 绝大多数的情况都是读比写多几十倍以上.
|