→ bluesoul: mutex是防止data race 你的情況應該是要別的 09/01 08:30
→ Eleina: close 前才 unlock 才能防止重複開啟吧? 09/01 10:20
→ Eleina: close 後 09/01 10:20
→ HolyBugTw: fcntl 09/01 10:22
推 shadow0326: 同2F 09/01 10:51
→ tjjh89017: 你應該要把app跟native lib的開檔都透過同一個路徑開啟 09/01 14:04
→ tjjh89017: 而不是分別由app跟native兩方自己去開 09/01 14:05
→ jaid: file lock 09/01 18:09
推 Hazukashiine: lock(&mutex) open(f) ... close(f) unlock(&mutex) 09/01 22:25
Eleina Hazukashiine大 我原文表達的不好 我的作法就如同兩位的意見是一樣的
不過還是會發生重複開檔的情形 不知道是不是因為不同process而無法擋掉
metux是只能擋同一process不同thread的情形嗎？
tjjh89017大 不太懂大大的意思 可在說明詳細嗎？
HolyBug jaid大 file lock我還沒有用過 會在試試看 謝謝
※ 編輯: chienchan (59.127.173.192), 09/01/2016 22:51:44
→ Eleina: mutex value 跟 address 印出來看看 09/01 23:20
推 shadow0326: 原來是不同process 那當然不行 09/02 00:40
推 james732: 改用Named semaphores？ 09/02 00:52
推 tjjh89017: 就例如說都交給native lib來檔案操作，app本身透過 09/02 01:12
→ tjjh89017: native lib來修改檔案，而不是自己另外開檔案來讀寫 09/02 01:12
→ Caesar08: 是喔。mutex這些東西是拿來用在同一個process的 09/02 01:15
→ Caesar08: 我錯了，pthread有cross process的mutex 09/02 01:19
→ Caesar08: 我想file lock應該才是你要的東西 09/02 01:20
→ descent: mutex 只能在同一個 process 不同 thread 用 09/02 09:11
→ descent: semaphore 或 file lock 對你才有用 09/02 09:12
推 hn12404988: std::mutex 是能跨std::thread的不是嗎？ 但有些linux 09/02 13:23
→ hn12404988: 本身會直接用posix thread代替std, 有的framework甚 09/02 13:23
→ hn12404988: 至是使用boost::thread, 不同thread有最適合的mutex, 09/02 13:23
→ hn12404988: 從你寫的，我猜不是std的，你可能要找framework manua 09/02 13:23
→ hn12404988: l來看 09/02 13:23
推 hn12404988: Sorry, 我剛重看，process間是各自獨立的，mutex不可 09/02 13:30
→ hn12404988: 能有用，我剛以為你在解決multi-thread問題 09/02 13:30
推 askacis: google flock 09/02 18:32
推 chiwa: 需要用到2個native lib的理由是? 我會覺得這樣的設計很怪 09/03 23:05