NX: URLYBird / my approach of the reading problem

[Max Habibi]

Originally posted by Vlad Rabkin:
Cool, one more supporter! Max where are you? Come back on the ring, let's fight, now I am not alone!

Down boy
Ok, I finally had a chance to dig into this, as well as look over my notes from the book. First, I want to congratulate Vlad for catching a very, very subtle point that a lot of other developers had missed. Nice job Vlad: if you ever need a job, drop me a line
However, the notifyAll in the lock method does serve a purpose, and does, IMO, belong in the method. Here's why.
The version of the exam that was being used at the time, FBNS, had a lock the entire database method key. That is, if Thread_1 were trying to lock record_1(but was in the wait pool for it), and thread_2 managed to lock record #-1, then Thead_1(and all other threads), needed to continue to stay in the wait pool, even if the record they wanted was released. Thus, the need for the notifyAll method in the lock method.
Now, the Denny's DVD example didn't have a lock record -1 criteria, but I wanted to make the transition over to the real exam as easy as possible. I was already using a data structure that was inappropriate for the SCJD(namely, a Vector). I didn't want the sample exercise to be too different, so I left that in there.
Anyway, the bottom line is the current version of the exam, since it doesn't have a lock entire DB mechanism, doesn't need the notifyAll in the lock method( nor did Denny's DVD, stickily speaking), but that's the reason it's there.
Make sense?
M
ps - Vlad: if you're having that drink, I think you need to buy me a shot too

[Jim Yingst]

Max, thanks for getting back to this. Unfortunately I don't quite follow the reasoning here. I know Max is busy, so if he doesn't respond right away perhaps someone else with access to the FBNS assignment can fill in some blanks for me.
The version of the exam that was being used at the time, FBNS, had a lock the entire database method key. That is, if Thread_1 were trying to lock record_1(but was in the wait pool for it), and thread_2 managed to lock record #-1, then Thead_1(and all other threads), needed to continue to stay in the wait pool, even if the record they wanted was released. Thus, the need for the notifyAll method in the lock method.
So, because thread_1 needs to stay in the wait pool, notifyAll() is used? How does notifyAll() help something stay in the wait pool? Isn't it used to help move something out of the wait pool? (Perhaps only temporarily, as the wait() is inside a loop, but still...) And why would thread_1 benefit from moving out of the wait pool when something was locked (either record -1 or another record)? Isn't thread-1 only interested in waking up when at least one record (or rec -1) is unlocked? What exactly is thread_1 going to do when it is awoken by notifyAll() immediately after something else has been locked? How does the new lock help?
Does this last post have anything to do with Max's earlier claim that a thread entering a sync block for the very first time might somehow benefit from receiving a notifyAll()? Has that argument been withdrawn, or does it have some role in the explanation given in this last past?
[ October 02, 2003: Message edited by: Jim Yingst ]

[Vlad Rabkin]

Hi Max,
Thanx you very much for your reply. Thanx you very much also for your good words addressed to me.
Honestly saying I didn't understand the case you described. So, I have the same question as Jim does. I am trying to reproduce the case you described to undestand what you ment, but if you had time to describe your idea a bit more in detail, it would be great.
Thank you very much for your time!
Best,
Vlad
[ October 03, 2003: Message edited by: Vlad Rabkin ]

[Max Habibi]

So, because thread_1 needs to stay in the wait pool, notifyAll() is used? How does notifyAll() help something stay in the wait pool? Isn't it used to help move something out of the wait pool? (Perhaps only temporarily, as the wait() is inside a loop, but still...) And why would thread_1 benefit from moving out of the wait pool when something was locked (either record -1 or another record)? Isn't thread-1 only interested in waking up when at least one record (or rec -1) is unlocked? What exactly is thread_1 going to do when it is awoken by notifyAll() immediately after something else has been locked? How does the new lock help?

Depending on your implementation decision, Thread_1 may simply choose to give up trying to lock record_1: thus, it would need to know that some other thread had locked record -1. Not an idea I recommended, but defendable.

Does this last post have anything to do with Max's earlier claim that a thread entering a sync block for the very first time might somehow benefit from receiving a notifyAll()? Has that argument been withdrawn, or does it have some role in the explanation given in this last past?
[ October 02, 2003: Message edited by: Jim Yingst ]

I think I failed to be clear. Of course I didn't mean that threads that have never waited by calling the map.wait method will benefit from a call to notifyAll. I meant threads like the above, which have yet to achieve the record. The terminology here is somewhat unsettling, because there are dual concepts of wait. There is waiting to enter a synchronized block, and there is the waiting by calling object.wait. My apologies if I failed to be clear.
M
[ October 03, 2003: Message edited by: Max Habibi ]

[Jim Yingst]

[Max]: Depending on your implementation decision, Thread_1 may simply choose to give up trying to lock record_1: thus, it would need to know that some other thread had locked record -1. Not an idea I recommended, but defendable.
OK, I see how this could fit in now, for some possible designs. Thanks.
I think I failed to be clear. Of course I didn't mean that threads that have never waited by calling the map.wait method will benefit from a call to notifyAll. I meant threads like the above, which have yet to achieve the record. The terminology here is somewhat unsettling, because there are dual concepts of wait. There is waiting to enter a synchronized block, and there is the waiting by calling object.wait. My apologies if I failed to be clear.
OK, cool. I was looking at this quote:

The issue is that there are threads who are trying just about to enter the synchronization block for the very first time, even as other threads have already done do. These (newbie) threads are blocked, because another thread currently has the monitor for reservedRecords. Now, when that thread calls notifyAll, then the threads who are trying to get the lock on reservedRecords for the very first time will get an opportunity to do so.

This seemed to be explicitly talking about threads trying to enter sync blocks, rather than threads which were in wait(). This was the main issue I was disagreeing with you on. As long as we're only talking about notifyAll() affected threads which are in wait(), then this is now resolved. Thanks again...

[Max Habibi]

Originally posted by Jim Yingst:
[Max]: Depending on your implementation decision, Thread_1 may simply choose to give up trying to lock record_1: thus, it would need to know that some other thread had locked record -1. Not an idea I recommended, but defendable.
OK, I see how this could fit in now, for some possible designs. Thanks.
I think I failed to be clear. Of course I didn't mean that threads that have never waited by calling the map.wait method will benefit from a call to notifyAll. I meant threads like the above, which have yet to achieve the record. The terminology here is somewhat unsettling, because there are dual concepts of wait. There is waiting to enter a synchronized block, and there is the waiting by calling object.wait. My apologies if I failed to be clear.
OK, cool. I was looking at this quote:

This seemed to be explicitly talking about threads trying to enter sync blocks, rather than threads which were in wait(). This was the main issue I was disagreeing with you on. As long as we're only talking about notifyAll() affected threads which are in wait(), then this is now resolved. Thanks again...

ugh, I can see how that's a terrible way to express myself. I was thinking about that fact that notifyAll ques up the threads in the object.wait pool. They, and other threads who are just waiting for the monitor(via the synch block), all compete, on an equal footing, for the lock. My (badly made) tangential point was that all threads compete equally, regardless of whether or not they're in the wait pool. I just didn't state it carefully. My apologies again if I confused anyone.
M
[ October 03, 2003: Message edited by: Max Habibi ]

[Vlad Rabkin]

Hi Max and Jim,

Thread_1 may simply choose to give up trying to lock record_1: thus, it would need to know that some other thread had locked record -1.

Finally, finally I understand it!!!
Thank you !
Vlad

[Max Habibi]

Originally posted by Vlad Rabkin:
Hi Max and Jim,

Finally, finally I understand it!!!
Thank you !
Vlad

Well, since it's taken some 86 posts, I obviously didn't explain it very well . I think you still get the 'win' here
M

[Jim Yingst]

My (badly made) tangential point was that all threads compete equally, regardless of whether or not they're in the wait pool.
Ah, enlightenment! OK, that I'll agree with too. (Umm, assuming you mean threads that were in the wait pool, and were subsequently notified, now they compete equally, unless they have different priorities...) Cheers...
[ October 03, 2003: Message edited by: Jim Yingst ]

[Jacques Bosch]

So Max never resolved the notifyAll() issue.

[Jacques Bosch]

OK, wait. Sorry. I didn't see there were more pages to this thread.