2009-01-28 52 views

回答

1

如果您確定只能從一個進程訪問它,則使用線程本地存儲中的文件句柄的讀寫鎖可能是一個解決方案。這隻會讓一個作家,而不是幾個讀者模擬上述情況。

2

我想這是acquire_file_lock

inline bool acquire_file_lock(file_handle_t hnd) 
{ 
    struct ::flock lock; 
    lock.l_type = F_WRLCK; 
    lock.l_whence = SEEK_SET; 
    lock.l_start = 0; 
    lock.l_len  = 0; 
    return -1 != ::fcntl(hnd, F_SETLKW, &lock); 
} 

它是一個non-boost implementation of a lock一致。

struct flock fl = {F_WRLCK, SEEK_SET, 0,  0,  0 }; 
    int fd; 

    fl.l_pid = getpid(); 

    if (argc > 1) 
     fl.l_type = F_RDLCK; 

    if ((fd = open("lockdemo.c", O_RDWR)) == -1) { 
     perror("open"); 
     exit(1); 
    } 

    printf("Press <RETURN> to try to get lock: "); 
    getchar(); 
    printf("Trying to get lock..."); 

    if (fcntl(fd, F_SETLKW, &fl) == -1) { 
     perror("fcntl"); 
     exit(1); 
    } 

    printf("got lock\n"); 
    printf("Press <RETURN> to 
3

文件鎖定API通常用於進程間鎖定。如果你在一個單一的過程中,所有在Boost.Thread package適合您的需求將做。應使用外部流程Boost.Interprocess。你可能想讀Boost.Interprocess中以下警告:

 
Caution: Synchronization limitations 

如果您打算使用文件鎖就像命名互斥體,要小心,因爲便攜式文件鎖有同步的限制,主要是因爲不同的實現(POSIX, Windows)提供不同的保證。進程間文件鎖具有以下限制:

  • 如果file_lock同步來自同一進程的兩個線程,則未指定它。
  • 如果一個進程可以使用兩個指向同一文件的對象file_lock,那麼它是未指定的。

第一個限制主要來自POSIX,因爲文件句柄是per-process屬性而不是per-thread屬性。這意味着如果一個線程使用一個file_lock對象來鎖定一個文件,其他線程會將該文件視爲鎖定。另一方面,Windows文件鎖定機制提供線程同步保證,因此嘗試鎖定已鎖定文件的線程會阻塞。

第二個限制來自文件鎖定同步狀態與Windows中的單個文件描述符綁定的事實。這意味着如果創建兩個file_lock對象指向同一個文件,則不保證同步。在POSIX中,如果描述符關閉時使用兩個文件描述符來鎖定文件,則清除調用進程設置的所有文件鎖定。

綜上所述,如果你打算使用文件鎖定在你的進程,請使用以下限制:

  • 對於每個文件,每個進程使用一個file_lock對象。
  • 使用相同的線程來鎖定和解鎖文件。
  • 如果使用std :: fstream/native文件句柄在該文件上使用文件鎖定時寫入文件,請不要在釋放文件的所有鎖之前關閉該文件。
相關問題