• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Problems for implementing readRecord & findByCriteria

 
pkinuk Buler
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all.

I am confused if these two method need to be synchronized.

My initial design is using caching the contractor information into a List<Contractor> object. The class Contractor is just contains 6 fields information(Location, Salary, Stuff...). My scenario is:

Thread a & Thread b is going to access my List<Contractor> object. Say Thread a run like:


When the Thread a gets the writeLock and is updaing the List<Contractor> (Assuming it will take a long time to finish the update procedure), meanwhile, Thread b wants to readRecord or findByCriteria:



Because the ReadWriteLock.writeLock is obtained by the Thread A. So the Thread B has to wait until the Thread A release the ReadWriteLock.writeLock. However, the my assignment said:
Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.


My questions:
1. Does mean I have failed if I used the above logic to implement the Interface?
2. Do I need to synchronize readRecord & findByCriteria? Is it a servious mistake if I don't synchronize readRecord & findByCriteria?

Regards,

Pkinuk





 
pkinuk Buler
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just check some inforamtion from internet.

blocking threads do not use CPU cycles


I think it my logic is OK for the requestment of my assignment:

Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.


Another question become borther me. What if the update procedure takes a long time to run in Thread A, in the mean time, Thread B is try to run the findByCritera method, will it cause a long delay for the Thread B?

Because my assignment doesn't request to step out the waiting for a specified time. Can I just let Thread B wait until Thread A release the lock?
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi pkinuk,

My remarks:

My initial design is using caching the contractor information into a List<Contractor> object.
I don't think a List is the best option to choose from Java Collections Framework to implement a record cache. I would suggest using a Map, more info about why you can find in this thread.

This thread is quiet similar to your question(s).

For your last question: in my solution I marked every (public) method in Data class as syncrhonized (in combination with wait/notifyAll), but you are not required to complete synchronize your methods. Of course you have to make your Data class completely thread-safe! So if you are reading a record from file (using raf.seek(); raf.read(); for example) you must make sure that no other thread can change the filepointer of the raf between seeking and reading or you'll read a completely wrong record. The approach I used is very simple and easy to understand, but certainly is not the most performant one. Yet another decision you have to take.

Kind regards,
Roel
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
pkinuk Buler wrote:Because my assignment doesn't request to step out the waiting for a specified time. Can I just let Thread B wait until Thread A release the lock?

On every line where you'll see a f, another thread can swoop in and perform a findByCriteria. But as long as a thread is inside the lock- or update-method, no findByCriteria can be executed (thread will have to wait until lock on data object is released).

Kind regards,
Roel
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic