A lot of where I saw the synchronization of threads. Usually it is associated with a certain shared resource. But I didn’t stumble upon a nuance. How to make it so that if there is not a single synchronization write operation, as it were, it would not exist at all, that is, a heap of threads can read the object at once. But only when the recording begins, everyone stops waiting for the final of the recording, just like the recording is waiting for the final of the reading.

For example, in java the synchronized block solves this task partially. When synchronized read() it will block not only synchronized write() but also all others to the read() call, right? Is it possible to avoid this and make it possible to cause reading as many times as necessary until the recording is called?

So reading is a lot of threads, writing is one?

  • A shared resource in your context is what? Db or something else? - Barmaley
  • Yes, whatever, a common resource is usually just a term to mean "an object that needs to be synchronized," that is, what several threads are trying to access. It can be just a counter in RAM in principle. - Uraty
  • Just in the case of a database, this is implemented differently, by the means of the database itself, which can be controlled when connecting with it - Barmaley
  • The database is already synchronized for you) If you write your database, you will have to provide for synchronization. - Uraty
  • 2
    Ok, it seems we don’t understand each other, leave it :) - Barmaley

2 answers 2

To do this, there is the ReadWriteLock interface and its implementation ReentrantReadWriteLock .

Example from this answer :

 class Store { private ReadWriteLock rwlock = new ReentrantReadWriteLock(); public void write() { rwlock.writeLock().lock(); try { //запись } finally { rwlock.writeLock().unlock(); } } public String read() { rwlock.readLock().lock(); try { //чтение } finally { rwlock.readLock().unlock(); } } }
  • I wonder how it is implemented inside. Is this something based on standard Java tools or Native? - Uraty
  • @Uraty looked a bit at the source code of the class ReentrantReadWriteLock - to understand a bunch of code, abstractions and their implementations is quite problematic. I did not find the native methods in the class. - Regent
  • So I also decided to look inside, I also did not find the native. But all is twisted on AbstractQueuedSynchronizer. Inside, something with a counter is muddied. Also did not drive too much) - Uraty
  • @Uraty yes, and the AbstractQueuedSynchronizer code is even bigger. Therefore, it remains only to believe the documentation (especially since it is not a third-party implementation) and experience of use. In the end, if you need the implementation of multiple non-blocking reads and blocking records, then there is one, and the main thing is to be able to use them correctly. - Regent
  • In theory, it is easy to build manually from the ordinary Lock 'a and condition variable . - VladD

You need, apparently, ReadWriteLock ( here ).

It allows you to lock exclusively for writing, or to block non-exclusive reading. That is, at each moment in time there will be access either from (all) readers, or from (one) writer.