UNIXプログラミング質問すれ Part7

>>948
% sysctl kern.cp_time; sleep 5; sysctl kern.cp_time
kern.cp_time: 51464 1204 77516 4733 1238731
kern.cp_time: 51502 1204 77531 4733 1238743
この増分は 38 0 15 0 12 となり、合計 65 のうち CP_IDLE (sys/resource.h)
は 12 だから 1 - (12 / 65) = 0.815... で CPU 利用率は 82% になる。

>>951
じゃあ次回からは「質問ある？」で

それだと質問あるかないか、ＹＥＳ，ＮＯのレスが続くだけのスレになるだろーが

無駄な「だろーが」入りました！

>>952
返信ありがとうございます。
ヒント、というか、そのものズバリを教えていただけるとは思いませんでした。
うーむ、mysysctlはsysctlを使うのと同じものだったとわ・・
ありがとうございました＾！

UNIX系の人って、IDE何使ってるの？

emacs

azumacs

カイヤ

POSIX共有メモリで構造体そのまんまで扱う時って定数構造体宣言して
mmapでよかったっけ？

あと、ファイルからデータ読み込む時
mmapでアタッチするのとopenのオプションにO_DIRECT付与するの
どっちが速いのでしょうか

どっちが速いかなどということは決まっていない
実測しろ

POSIX共有メモリって普通IPCのshm*(2)のことだけどな。
旧称System V共有メモリ

O_DIRECTって意味分かってないだろ。>>961
ちゃんとマニュアル読めよ。

mmapされたシェアードメモリを複数プロセスで
read/writeする必要があるんですが,ロックに関しては
どうするのが安全/高速ですか？
ロックに関してはアドバイザリーロックで問題ありません.

OSはFreeBSDもしくはLinuxです.

>>965
一般的にはセマフォ。

>>965
mlockでいいんじゃね?

mlockは排他制御には使えないとおもうがどうか

無理すぎ

>>966
ありがとうございます.調べてみたところ,

名前付きセマフォ: カーネル内にロック情報を保持
メモリベースセマフォ: プロセス共通のSharedMemory内にロック情報を保持
SysVセマフォ: カーネル内にロック情報を保持
pthread_mutex: プロセス共通のSharedMemory内にロック情報を保持
pthread_rwlock: プロセス共通のSharedMemory内にロック情報を保持

って感じでになってて,プロセスの異常終了時のロックの
解放に関してはそれぞれ特徴があるみたいですね.

ロック期間中に変更したデータの整合性に関しては
プログラマ側に任されているみたいで,安全性に関しては
等価な印象です(間違ってたら指摘お願いします).

追加質問なのですが,FreeBSDもLinuxもセマフォに関しては
扱える上限数がカーネル設定で固定されているようです.
これを考えるとメモリアル限り自由にロックの粒度を
細かくできるmutexの方が使いやすいと思うんですが,
どうなんでしょう?

>>967
今回の目的は確保したSharedMemoryを破壊しないように
同期のLockを行いたいというものでした.

mlock()は確保したメモリをswapさせないようにする関数なので,
今回の用途とは少し違うかと思います.

すいません.質問の仕方が悪かったみたいです

ディレクトリ一覧を再帰的に取得する方法について質問です。
manのftsを見ながら即興で組んでみたのですが、
（変数名適当です・・・）
以下のプログラムだと、/usr/以下の全ディレクトリ以外に
ファイル名も出力してしまいます。
ディレクトリ名のみを出力する方法はないでしょうか・・・

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fts.h>

main(){
FTS *dir;
FTSENT *fts;
char *path[2]={"/usr", NULL};
if((dir=fts_open(path,FTS_PHYSICAL|FTS_NOCHDIR,NULL))==NULL){
perror("opendir error");
exit(-1);
}

for(fts=fts_read(dir);fts!=NULL;fts=fts_read(dir)){
printf("%s\n",fts->fts_path);
}
close(dir);
return 0;

}

>>972
fts_statp を見ろ

FTS_Fでも抑制したら。

>>972
if (fts->fts_info == FTS_D)
  printf("%s\n",fts->fts_path);

>>972
>>973
>>974

なるほど、ヘッダファイルでFTS_Dを1としてdefineしていたんですね・・・
今までそれがわからずにcoreを吐かせまくってましたが、
おかげさまで狙い通りの値がとれるようになりました。
ttp://mirror.sg.depaul.edu/pub/OpenBSD/src/include/fts.h
ありがとうございました！

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fts.h>
main(){
FTS *dir;
FTSENT *fts;
char *path[2]={"/usr", NULL};
if((dir=fts_open(path,FTS_PHYSICAL,NULL))==NULL){
perror("opendir error");
exit(-1);
}
for(fts=fts_read(dir);fts!=NULL;fts=fts_read(dir)){
/* FTS_D is defined as 1 in fts.h */
if(fts->fts_info==FTS_D){
printf("%s\n",fts->fts_path);
}
}
fts_close(dir);
return 0;
}

>>976
1 だとか 2 だとかコメントに書かないほうが良いよ。
別の OS で FTS_D が 2 だったら、コメントも変えるの？

>>970
Linux なら /proc/sys/kernel/sem で拡張できるよ

>>978
>Linux なら /proc/sys/kernel/sem で拡張できるよ

情報ありがとうございます.FreeBSDならkern.ipc.semm*
あたりで変更できますね.
FreeBSDもLinuxも内部機構を知らないのでなんなのですが,
OS側で数を制限しているからには数を増やすとそれなりに
パフォーマンスが落ちると思うんですね.

mutexの場合はロックの粒度に応じてthread_mutex_tの変数を
プロセス共通のシェアードメモリに必要なだけ確保すればいい
だけなので,セマフォより使いやすいのかなと思ったんです.

ところで次のスレはこの板に作っちゃっていいんでしょうか?
Unix板でやれという意見もあるようですが.

UNIXのプログラムの質問をするスレなんだからプログラム板だろ

>>979
pthread_mutexがprocessを越えても有効かどうかは環境依存。

>>982
>pthread_mutexがprocessを越えても有効かどうかは環境依存

なるほど.情報ありがとうございます.調べてみたところ
確かにその通りでした.
PTHREAD_PROCESS_SHARED
はLinuxではNativeでサポート,FreeBSDは未サポートなので、
portsでlinuxthreadsを入れる必要があるようですね.

http://www.unobvious.com/bsd/freebsd-threads.html

>>981
UNIXのプログラムの質問をするスレなんだからUNIX板だろ

>>984
どっちでもいいから、次スレは同じ板に立てるのがデフォルトってことで、プログラム板だろ。

UNIXを目の仇にしてるごく一部のおかしな人が暴れてただけだからなあ。
この板で全然いいでしょう。

>>984
WIN32APIのスレで同じこと言えよ。

両方にあってもいいわけだし。

両方あるな
＞プログラミング質問すれ Part1 http://pc8.2ch.net/test/read.cgi/unix/1127388574/

次スレ
UNIXプログラミング質問すれ Part8
http://pc8.2ch.net/test/read.cgi/tech/1147946176/

>>990乙

a

b

c

d

e

f

g

h

i

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。