• Post Reply Bookmark Topic Watch Topic
  • New Topic

Synchronization for a "read-often write-rarely" class?

 
Galen Palmer
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a class where there are bunch of read functions that are accessed frequently and an update function that will be used infrequently but should block all the read functions until it is complete.

I'm not sure about the terminology used in java.util.concurrent.lock so Im not sure if there's a solution in there.

Here's my requirements:
1. Multiple concurrent reads should be allowed
2. The update functions corrupt the inner model so all read methods should placed on hold until the update is complete

I was reading the Semephore docs and wondered if that was a starting point. IN essence, I'd want a version that provided an infinite number of permits for reads (since reads don't interfere with each other) but when one of the update methods was called needed to start it would wait for all existing reads to complete then revoke all permits before starting the update.

The higher level question: is there a term that describes this particular type of problem (or its solution)? Semephore doesn't seem to quite encapsulate what I'm looking for.

The lower level question: how might one solve this?

Thanks!
 
Jelle Klap
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Would a copy-on-write (COW) strategy be acceptable in this scenario?
 
Henry Wong
author
Sheriff
Posts: 22528
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Take a look at the Reader Writer Lock. Here is a reference to the JavaDoc...

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html

For reading, threads will grab the read lock, which allows parallel reads. For writing, threads will grab the write lock, which blocks other writers, (and the readers).

Henry
 
Henry Wong
author
Sheriff
Posts: 22528
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And BTW, since you mentioned write-rarely, I would also like to mention that the reader writer lock does have a mechanism to prevent starvation. For example...

If a bunch of readers come in, they will all be given access. If a writer comes in, it will be queued behind the readers. If more readers come in, they will *not* be allowed to skip the writer, even though, technically, they can work in parallel with the first batch of readers.

The reason is to prevent starvation of the writer. It is theoritically possible for readers to keep coming, and if skipping is allowed, it is possible for the writer to never get the lock. So, no skipping...

Henry
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!