Locking, about sentence: "consuming no CPU cycles"

[Roby Kappa]

In instructions there is this sentence:

"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. "

In my solution, I use a wait statement in order to pause current thread execution until the resource is available. To avoid infinite waiting for the client, I used wait(TIMEOUT) with a timeout value for example, of 2 seconds. This statement is in a while loop, that ends when the total waiting time is > 10 seconds. In this case a RuntimeException is raised in order to inform the client that the resource is unavailable.

In your opinion, is this solution correct in order to "consuming no CPU cycles until the desired resource becomes available"? In my solution the system consumes few cpu cycles to verify (five times) if the resource is available. Is this correct?

[Jethro Borsje]

I think this is correct.

[Andrew Monkhouse]

My understanding of your solution is that after 10 seconds the timeout will occur, at which point the client thread will start consuming CPU cycles again as it handles the error.

Seems to me that this is in direct conflict with the comment that no CPU cycles should be consumed until the lock is released.

Whether this is a problem or not is for you to decide - you are allowed to make design decisions (and in some cases you must make decisions on conflicting requirements) and having made the decision you can then document it. I believe others have passed while breaking the contract by having timeouts.

Personally I chose to honor the contract, even though it could mean that client B could be blocked indefinitely while waiting for client A to release their lock. I also had logic in my solution such that if client A disconnected while still holding a lock, then it would be released by the server, thereby freeing it for client B.

Regards, Andrew

[Sebastian Puzon]

Hi!

I wanted to start new thread about similar topic, but let do this here...

My assignment is UrlyBird 1.3.2, where I'm tracking lock owner by token.

I have implemented two solutions (still wondering which should I choose):

1st - The simplest locking mechanism with one mutex on Map<Long, Long>. The key is record number, under value I store cookie (random long). Threads are notified by notifyAll()(it has to be notifyAll() please read similar threads). By waking up all thread I'm violating contract ( not always that record will be unlocked which Thread waits for) Other disadvantage may be that it may cause unnecessary CPU burst.

2nd - Hand-Over-Hand, please read Andrew's sample in his great book! It does not violate contract about "consuming no CPU cycles until the desired resource becomes available", but it's more complex. I see one problem there - locks are added to map but they are never removed. Map may grow and grow to the size equal to number of valid records in db. That's the scalability problem!

I prefer 2nd solution since it's more efficient and does not violate contract. On other hand it looks like SUN does not subtract points if You choose 1st.

I also found in book this sentence

For the SCJD exam, scalability and performance are not design considerations.

. Guys can You confirm that?

So 1st is performance issue, and 2nd scalability.

I think I'll go with 2nd (I like it, except remove()

Did anyone found solution for remove()?
Did anyone decided to go with hand-over-hand and what was final score ?

Regards
Sebastian.

[Alex Belisle Turcot]

Hi Sebastian,

You're better off starting new threads for new question otherwise a lot or people will not see it as some will only look at new threads.

You do realize that your quote " For the SCJD exam, scalability and performance are not design considerations." is saying that you should not care about performance and scalability.

So any design decision based on performance or scalability can just be ignored. The best solution for this assignment is the simplest one that meets the functional requirements.

Regards,
Alex
[ October 09, 2008: Message edited by: Alex Belisle Turcot ]

[Sebastian Puzon]

Thanks Alex for advice! I'll start new thread. BTW I can admit that 1st solution is really simple, only few lines of code. I'm sure that junior developer will understand it.

Sebastian.