问几个风水的问题 - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Living

问几个风水的问题

问几个风水的问题# Living

a*d2012-02-27 08:02

1 楼

先问个问题，read-write lock里要实现当lock请求过来之后，让所有reader都read完
然后再去write lock，是不是再加一个mutex还是只check semaphore就行了？（只有一
个写锁，n读锁）。这方面脑子不清楚...
然后是小感一下，进门等候的时候看见氛围不错，路过的人脸上笑容挺不少，后来发现
不是开发部，等到了开发部，就阴沉了很多，大家表情严肃，一些调程序的人的控制台
程序屏幕不停刷着，比较闷。面试的人都很nice，期待这家能有好的回馈。

j*e2012-02-27 08:02

2 楼

最近在看房，有风水问题几个请教：
1. 扇形的lot(前宽厚尖)到底是好还是不好？
2. 门前的circular driveway算不算反弓？
3. 开门就是上二楼的楼梯是凶是吉？
多谢指教。

x*62012-02-27 08:02

3 楼

我怎么感觉应该用CountDownLatch

h*32012-02-27 08:02

4 楼

counting semphore？

r*g2012-02-27 08:02

5 楼

如果只read，是不是不用mutex了啊？lz有啥hint不？

【在 a********d 的大作中提到】

: 先问个问题，read-write lock里要实现当lock请求过来之后，让所有reader都read完
: 然后再去write lock，是不是再加一个mutex还是只check semaphore就行了？（只有一
: 个写锁，n读锁）。这方面脑子不清楚...
: 然后是小感一下，进门等候的时候看见氛围不错，路过的人脸上笑容挺不少，后来发现
: 不是开发部，等到了开发部，就阴沉了很多，大家表情严肃，一些调程序的人的控制台
: 程序屏幕不停刷着，比较闷。面试的人都很nice，期待这家能有好的回馈。

a*d2012-02-27 08:02

6 楼

这个还真没用过，看了看感觉区别据说是这样：
CountDownLatch是一组线程等待所有的线程都结束或者计数结束。
semaphore控制同时对资源访问的数量。
问题是semaphore上下浮动，如何控制说一个write过来了，控制semaphore数量直到0？
额外的mutex还是啥？迷糊了已经。

【在 x*******6 的大作中提到】

: 我怎么感觉应该用CountDownLatch

x*62012-02-27 08:02

7 楼

你的意思是当要write的时候，让所有reader停止，然后write？
这个可以把所有的read task放到一个ExecutorService里执行，要write的时候把它
shutdown并且awaitTermination（）到所有task执行完。然后再连上writer执行write
。不知道这样对不对。

【在 a********d 的大作中提到】

: 这个还真没用过，看了看感觉区别据说是这样：
: CountDownLatch是一组线程等待所有的线程都结束或者计数结束。
: semaphore控制同时对资源访问的数量。
: 问题是semaphore上下浮动，如何控制说一个write过来了，控制semaphore数量直到0？
: 额外的mutex还是啥？迷糊了已经。

r*s2012-02-27 08:02

8 楼

扯淡，这就是要你写的时候acuire所有的read lock，就像concurrenthashmap里面的
size。
所有的read进来都要等write待lock。所以write先acuire那个write lock，后面的read
就进不来了，然后再一个一个地acquire那些read lock。
实在看不过去，愤然发帖指正。

B*12012-02-27 08:02

9 楼

似乎就是这个吧。
http://doc.qt.nokia.com/qq/qq11-mutex.html

a*d2012-02-27 08:02

10 楼

多谢，就是这个了，之前就不知道那个读的semaphore应该怎么冒到limit，看了发现一
个循环加上去，哎...真是浆糊。

【在 B*******1 的大作中提到】

: 似乎就是这个吧。
: http://doc.qt.nokia.com/qq/qq11-mutex.html

a*d2012-02-27 08:02

11 楼

呵呵，轻喷，学习了。
看了楼下贴的链接，发现好像是没有让read都要等待write lock，而是一个write lock
放mutex，然后开始一个一个收semaphore，收到满然后执行write后semaphore全放掉。
这样省了read去看write lock。不知道理解对不对，望指正。

read

【在 r****s 的大作中提到】

: 扯淡，这就是要你写的时候acuire所有的read lock，就像concurrenthashmap里面的
: size。
: 所有的read进来都要等write待lock。所以write先acuire那个write lock，后面的read
: 就进不来了，然后再一个一个地acquire那些read lock。
: 实在看不过去，愤然发帖指正。

x*62012-02-27 08:02

12 楼

确实是这样，学习了。

r*s2012-02-27 08:02

13 楼

lock
read 不需要看mutex吗？
另外semaphore没有一个一个的说法，semaphore里有permit。

【在 a********d 的大作中提到】

: 呵呵，轻喷，学习了。
: 看了楼下贴的链接，发现好像是没有让read都要等待write lock，而是一个write lock
: 放mutex，然后开始一个一个收semaphore，收到满然后执行write后semaphore全放掉。
: 这样省了read去看write lock。不知道理解对不对，望指正。
:
: read

a*d2012-02-27 08:02

14 楼

确实，这个实现里面对这个有点宽容，就是write在收semaphore的时候并不保证在全部
收走之前读不会进来，这也算是这个简洁设计的小缺陷，不过应该可以忍。

【在 r****s 的大作中提到】

:
: lock
: read 不需要看mutex吗？
: 另外semaphore没有一个一个的说法，semaphore里有permit。

r*s2012-02-27 08:02

15 楼

绝大多数的情况都是读比写多几十倍以上.

a*d2012-02-27 08:02

16 楼

恩，好在收semaphore的循环是不可逆的，eventually会归0，只是没那么快。
多谢解答。

【在 r****s 的大作中提到】

: 绝大多数的情况都是读比写多几十倍以上.