• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Concurrency

 
Keith Jones
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I have a question about the DBMain interface and the Data class that implements it.

My confusing lies in understanding how the concurrency is meant to work. Now, given that the application is going to be multithreaded my understanding is that only one client can read or write one RECORD at a time. However, I think that more than one client can read or write to the file at one time though otherwise what we would be the point of the lock and unlock methods? But, here's where i get even more confused, surely if two processes tried to write to the same file at the same time (of course it won't be the same time exactly because there is only 1 processor) then the contents of the file could get corrupted. For example if 1 thread is half way through creating a new record and then gets interupted by another thread which has the aim of updating a second record surely when we read the data file we will get problems with data consistency since the first thread has only created partial data.

If on the other hand we don't allow interruptions of the first thread until the entire record is written then is there even any point in the multithreadedness.

Your wise clarifications will be most appreciated.

Keith
 
Mike Ngo
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You synchronize the code that actually read/write to the file so that at any given time only one thread has access to the file.
 
Keith Jones
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok here a few more queries:

1. Does the lock method need to be synchronised? I say this because if it isn't then won't it be possible that half way through the execution of the method another thread may try and lock another (or the same) record?
2. When the specification of the lock method says:

"If the specified record is already locked, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked."

What does this mean?

cheers
 
Keith Jones
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok here a few more queries:

1. Does the lock method need to be synchronised? I say this because if it isn't then won't it be possible that half way through the execution of the method another thread may try and lock another (or the same) record?
2. When the specification of the lock method says:

"If the specified record is already locked, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked."

What does this mean?

cheers
 
Keith Jones
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

Sorry about posting the previous message twice - that was accidental. Does anyone have an answer to this. I'm really stuck.
 
Mike Ngo
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It means that if a client calls lock() and the record is locked, that client waits for the lock to be unlocked.
 
Chulwoo Choi
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The lockRecord method doesn�t have to be a synchronized method. Instead, inside the method, you should have a synchronized block having a while loop checking whether the record can be locked. If a thread can't lock the record it will wait. Note a waiting thread doesn't consume CPU time. The relevant pseudo-code looks like:

This is the standard idiom for using the wait method. (quote from Item 50, Effective Java by Bloch) (Note if you use Java 5 locking features, codes will look different but the structure is the same.)

Say, there are 3 threads (T1, T2, T3) trying to call lock method to lock a record.
  • T1 will enter the while loop and will lock the record. Note T2, T3 can't enter the loop as the loop is in the synchronized block (see above).
  • Now, T1 is done. The caller (GUI client) of lock method gets the cookie which is generated/returned by the lock method. (The caller uses the cookie to update/delete record.)
  • T2 enters the loop and waits as the record is locked by other thread (see <condition does not hold> in while loop above). Note T2 doesn't consume CPU time while waiting. And it (T2) releases its lock on obj so T3 can enters the while loop but it also waits.
  • T2, T3 are stuck in the while loop waiting...
  • The GUI client (who was associated with T1) calls unlock with the cookie. Inside the unlock method, <condition does not hold> is changed to <condition now holds> and obj.notifyAll() is called.
  • T2, T3 are awaken and one of them is scheduled to proceed to lock the record...


  • Chulwoo
     
    Chulwoo Choi
    Ranch Hand
    Posts: 65
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Sorry,
    In my previous post change to )


    Chulwoo
     
    Keith Jones
    Ranch Hand
    Posts: 105
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Chulwoo Choi:
    The lockRecord method doesn�t have to be a synchronized method. Instead, inside the method, you should have a synchronized block having a while loop checking whether the record can be locked. If a thread can't lock the record it will wait. Note a waiting thread doesn't consume CPU time. The relevant pseudo-code looks like:

    This is the standard idiom for using the wait method. (quote from Item 50, Effective Java by Bloch) (Note if you use Java 5 locking features, codes will look different but the structure is the same.)

    Say, there are 3 threads (T1, T2, T3) trying to call lock method to lock a record.
  • T1 will enter the while loop and will lock the record. Note T2, T3 can't enter the loop as the loop is in the synchronized block (see above).
  • Now, T1 is done. The caller (GUI client) of lock method gets the cookie which is generated/returned by the lock method. (The caller uses the cookie to update/delete record.)
  • T2 enters the loop and waits as the record is locked by other thread (see <condition does not hold> in while loop above). Note T2 doesn't consume CPU time while waiting. And it (T2) releases its lock on obj so T3 can enters the while loop but it also waits.
  • T2, T3 are stuck in the while loop waiting...
  • The GUI client (who was associated with T1) calls unlock with the cookie. Inside the unlock method, <condition does not hold> is changed to <condition now holds> and obj.notifyAll() is called.
  • T2, T3 are awaken and one of them is scheduled to proceed to lock the record...


  • Chulwoo


    Thanks for the information Chulwoo,

    Just a few clarifications though.

    1. The obj in the synchronised block would be the datastructure that stores the list of locked records right?
    2. Would I right in saying that there should be only 1 instance of this datastructure shared by all clients because otherwise if all clients have their own list of locked records there would be no way of determining whether a particular record is locked?

    Cheers
     
    Chulwoo Choi
    Ranch Hand
    Posts: 65
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi,

    obj is just a lock that is used for synchronizing the access. It can be anything, for e.g.,

    A thread can enter the synchronized block as long as no other thread is already in the block (i.e., as long as no other thread already holds the lock). In the block, the thread does something and gets out of the block. At this point, obj (lock) is released (i.e. becomes available for others) and other thread can get in the block. The lock is also released when the thread calls wait() on obj.
    Note as you use Java 5, you could use explicit locking classes (ReentrantLock, Condition, etc.) in your locking codes.

    I'm not sure what you mean "datastructure" but...
    There is one database file and one Data instance (which accesses the database file; maybe a singleton) on the server-side. So multiple networked clients will talk to the only instance of Data.
    i.e. Many clients but one data file and data access object.

    Regards,
    Chulwoo
     
    Chulwoo Choi
    Ranch Hand
    Posts: 65
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Oops,



    Chulwoo
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic