file lock을 쓰레드에서는 쓸수 없나요?

다음과 같은 소스에서
#include
#include
#include
#include
#include
void *do_write(void *data)
{
int fp;
struct flock lType;
fp = open("./test.txt", O_RDWR | O_CREAT);
lType.l_type = F_WRLCK;
lType.l_whence = SEEK_SET;
lType.l_start = 2;
lType.l_len = 2;
fcntl(fp, F_SETLKW, lType);
printf("1 is lock now!!\n");
sleep(4);
lType.l_type = F_UNLCK;
fcntl(fp, F_SETLKW, lType);
printf("1 is unlock now!!\n");
sleep(5);
}
void *do_read(void *data)
{
int fp;
struct flock lType;
fp = open("./test.txt", O_RDWR | O_CREAT);
sleep(2);
lType.l_type = F_WRLCK;
lType.l_whence = SEEK_SET;
lType.l_start = 2;
lType.l_len = 2;
printf("2 is try lock now!!\n");
fcntl(fp, F_SETLKW, lType);
printf("2 is get lock now!!\n");
sleep(2);
lType.l_type = F_UNLCK;
fcntl(fp, F_SETLKW, lType);
printf("2 is unlock now!!\n");
sleep(5);
}
int main()
{
pthread_t p_thread[5];
int thr_id;
int status;
int a = 1;
int b = 2;
FILE *fp;
char arr[10];
fp = fopen("./test.txt", "w");
fprintf(fp, "123456789");
fclose(fp);
thr_id = pthread_create(&p_thread[0], NULL, do_write, (void *)&a);
thr_id = pthread_create(&p_thread[1], NULL, do_read, (void *)&b);
pthread_join(p_thread[0], (void **) status);
pthread_join(p_thread[1], (void **) status);
return 0;
}
컴파일후 실행을 하니
$ ./a.out
1 is lock now!!
2 is try lock now!!
2 is get lock now!!
1 is unlock now!!
2 is unlock now!!
$
위와 같은 결과가 나옵니다..
저의 생각으로는
1 is lock now!!
2 is try lock now!!
1 is unlock now!!
2 is get lock now!!
2 is unlock now!!
이렇게 나와야 할것 같거든요....
뭐가 잘못된건지.. 아니면 쓰레드에서는 file lock을 쓸수 없는건가요?
Re: file lock을 쓰레드에서는 쓸수 없나요?
man 페이지를 보면..
fcntl - 파일 기술자(file descriptor) 조작
사용법
#include
#include
int fcntl(int fd, int cmd);
int fcntl(int fd, int cmd, long arg);
int fcntl(int fd, int cmd, struct flock * lock);
이렇습니다..
int fcntl(int fd, int cmd, struct flock * lock);
에서 3번째 인자를 넘길때... 포인터를 넘겨야 하죠..
fcntl(fp, F_SETLKW, lType); 를
fcntl(fp, F_SETLKW, &lType); 이렇게 바꿔야 겠죠..
그리고 잠금 같은 경우엔...
rtn = fcntl(fp, F_SETLKW, &lType);
식으로 해서 rtn값을 체크할 필요가 있습니다..
이것은 여담이지만.. 잠금의 빠르기를 벤치마크한 경우가 있는데.
AcceptMutex
Introduced in Apache 1.3.21 and in Apache 2.0, the AcceptMutex
directive reveals a significant opportunity for performance tuning.
This directive allows configuration at runtime of how Apache will
tune accept() handling. On some systems with only a single listener,
accept locking is not required. This strategy is called Single
Listen Unserialized Accept (SLUA). However, for those configurations
that have multiple listeners or operating systems that have a
thundering herd on the accept system call (no matter the number of
listeners), the accept routines must be serialized.
Sander Temme of Covalent did some performance analysis of the accept
() locking strategies. This report led to the current ordering in
Apache 1.3.21 as listed here
Irix's uslock (uslock)
POSIX cross-process locks (pthread)
SystemV Semaphores (sysvsem)
fcntl() locking (fcntl)
flock() locking (flock)
OS/2 Semaphores (os2sem)
TPF locking (tpfcore)
None
이런 순이랍니다...
pthread가 파일 락킹 보다는 빠르지요..;;
댓글 달기