Java: RandomAccessFile thread-safe

Question

Dopo un po 'di googleing serio ho scoperto che la classe RandomAccessFile non è thread-safe. Ora potrei usare un semaforo per bloccare tutte le letture e le scritture, ma non penso che funzioni molto bene. In teoria dovrebbe essere possibile fare più letture e una scrittura alla volta. Come posso farlo in Java? È possibile a tutti?

Grazie!

Answer 1

Il blocco parziale di un file è un'attività complessa che molti sistemi operativi non riescono a fare. Tuttavia, se si insiste a farlo, un modo è quello di progettare il proprio oggetto meccanismo di blocco che registra quali parti del file sono bloccate. In sostanza, prima di leggere o scrivere un oggetto è necessario richiedere un blocco per un intervallo di byte specifico del file. I blocchi vengono considerati in conflitto se si sovrappongono del tutto nell'intervallo di byte. I blocchi di lettura e scrittura sono trattati in modo diverso: una lettura può sovrapporsi con qualsiasi numero di blocchi di lettura in modo sicuro, ma un blocco di scrittura deve sovrapporsi senza altri blocchi, leggere o scrivere. Ci sono molte domande su se aspettare o interrompere se non riesci a ottenere il blocco e se bloccare le letture mentre una scrittura è in attesa, ma solo tu puoi rispondere loro della tua applicazione.

Data la complessità di questo potrebbe essere meglio bloccare l'intero file. Controlla se ottieni prestazioni adeguate e non dimenticare che puoi consentire più letture contemporaneamente, a condizione che non ci siano scritture.

Answer 2

ho potuto utilizzare un semaforo per bloccare tutte le di lettura e scrittura, ma non credo che esegue molto bene.

Per quanto riguarda le prestazioni, non pensate MAI. Misura SEMPRE.

Detto questo, java.util.concurrent.locks.ReentrantReadWriteLock è quello che stai cercando.

Answer 3

Considera questo approccio - consente un numero illimitato di lettori, e quando uno scrittore vuole scrivere, aspetta che i lettori attuali finiscano di scrivere.

class readWriteSemaphore() { 
    private Object lock; 
    List<Thread> readers; 
    Thread writer; 

    readWriteSemaphore() { 
     readers = new LinkedList<Thread>(); // Linked list is inefficient for many threads, FYI 
     writer = null; 
    } 

    /** 
    * Returns true if and only if you have acquired a read 
    * maybe use while(!rws.acquireRead(Thread.currentThread())) Thread.sleep(50); // or something 
    */ 
    boolean acquireRead(Thread t) { 
     synchronized(lock) { 
      if(writer == null) { 
       readers.add(t); 
       return true; 
      } 
      return false; // yes this could go outside the synch block... oh well 
     } 
    } 

    void releaseRead(Thread t) { 
     synchronized(lock) { 
      while(readers.remove(t)); // remove this thread completely 
     } 
    } 

    boolean acquireWrite(Thread t) { 
     synchronized(lock) { 
      if(writer == null) return false; 
      writer = t; 
     } 
     while(readers.size() > 0) Thread.sleep(50); // give readers time to finish. 
     //They can't re-enter yet because we set the writer, 
     // if you attempt to acquire a write, future reads will be false until you're done 
     return true; 
    } 

    void releaseWrite(Thread t) { 
     synchronized(lock) { 
      if(t != writer) throw new IllegalArgumentException("Only writer can release itself"); 
      writer = null; 
     } 
    } 

} 

Answer 4

Se un semplice mutex sull'intero file sta per darvi un collo di bottiglia, e RandomAccessFile non è thread-safe senza un mutex, allora avete bisogno di cercare alternative per RandomAccessFile.

Un'alternativa consiste nel mappare il file in memoria come MappedBuffer e utilizzare le sezioni del buffer per consentire a diversi thread di accedere al file senza interferire l'uno con l'altro. Un singolo scrittore/blocco di più lettori alla granularità dell'intero sarebbe facile da implementare. Si potrebbe anche andare oltre e implementare la lettura e la scrittura simultanee di sezioni non sovrapposte del file, ma sarebbe più complicato.

Non sarei sorpreso di sentire che qualcuno, da qualche parte, lo ha già implementato come libreria riutilizzabile.