File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes testing concurrency and sleeping threads Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "testing concurrency and sleeping threads" Watch "testing concurrency and sleeping threads" New topic
Author

testing concurrency and sleeping threads

Dmitri Christo
Ranch Hand

Joined: Jan 19, 2007
Posts: 81
Hi, I have reached the stage where I need to test my locking strategy and the multi-threading behavior of my assignment so far. I am not using JUnit yet, but created a simple test where multiple threads try to lock and update the same record (room):


For example a sample output is:


The above looks normal to me, but what worries me, is that it seems the application remains stuck, or launching indefinitely without terminating, although the above is a copy of the complete output.

However when I make each thread sleep for a few milliseconds, the output is completely different:

In this case it almost looks like the first thread never wakes up? Is there an explanation I am missing perhaps? I looked up again the static sleep() method, and the thread is not supposed to give up its lock/monitor of the synchronized block it is running in...(this is not to be confused with the logical lock/unlock specification of the assignment).

Also, in Eclipse console it seems as the launch hasn't terminated yet (true for both tests, when sleep is off and then on), so I am forced to press the red square on the console to manually terminate the launch.

Could it be a setting in my Eclipse environment, or something else might be wrong with how I created this test?

Anyone perhaps faced something similar in the past? Thanks for any advice.
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

would it be right to say, that in your 1st output, only 5 threads successfully complete ?
T1, T2, T3, T5 do not appear. And T7 locks but never unlocks the room:



I would add a n additional "System.out" in your lock and unlock methods, I would suspect the logic might be wrong..


In your 2nd ouput:



A quick suspicion is that your T0 is blocked in your "unlock" method..
It might make sense, T0 holds the lock while another thread is in your synchronized block, then T0 arrives and is blocked at the synchronized. And the other thread is waiting for T0 to release the resource.

Do you use "wait" in your synchronized block, when the resource is not available ?

I hope I'm not too far from anything intelligent.

Regards,
Alex
Dmitri Christo
Ranch Hand

Joined: Jan 19, 2007
Posts: 81
Thanks for the suggestions.


Do you use "wait" in your synchronized block, when the resource is not available ?

Yes, I use wait in the lock method and then a notifyAll in the unlock method. But, when a thread already inside a synchronized block, calls sleep(), does not give up its lock right? I mean in theory, after the sleep time is over, the same thread should pick up where it left of in that synchronized block, because it never gave up its lock. Unless I am totally wrong here. Of course the scheduler will put it in the 'runnable' pool, but when it is selected to go into 'running' state, it will still has the lock for that synchronized block..

As far as the first output is concerned. It is strange why only some of the threads actually got to run. Why the logic worked for some of the threads and not for the rest?

Could there be an obvious error with my logic that I overlooked?
In the lock manager class


..and in the wrapping class:


Again, thanks for any insight.
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

I'm always a little uncomfortable when compilable code from lock/unlock are pasted.. I'm not sure the rules, but this is arguably the main part of the certification. So I wouldn't want debug it line by line.

It might be a good idea to remove it also.. Speudo-code is acceptable
Dmitri Christo
Ranch Hand

Joined: Jan 19, 2007
Posts: 81
I know what you mean. But this is not an exact copy/paste of my locking code, nor does it expose the entire logic. I just thought it might help viewers interested in the issue I am facing with my testing, to make educated comments.

Besides if you search this forum you can easily see way more detailed code than this one posted and commented upon. But, If the moderators say so, I will gladly remove all or part of it though.

I would definitely welcome any other comments you, or any other might have regarding this issue however.

Thanks
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

Could you try something else for me.. try to comment out your "update", see if all the threads will finish this time.

From the information you showed, it looks fine, but perhaps something evil is performed in your update ?

Do you alter the HashMap in your update ? Could you show me the output when update is commented out (if you have other operation, comment them as well... just keep lock/unlock, with alternatively a sleep in between).

Regards,
Alex
Dmitri Christo
Ranch Hand

Joined: Jan 19, 2007
Posts: 81
This is the output when update() is bypassed, without any sleeping:



Perhaps you have a valid point here. Then the same execution with sleep (inside run), and without update:

..and then as soon as I un-comment the update() - with the rest kept the same:

..The main method never ends, as it does in both previous occasions..
Also, not even the first thread gets to complete an update..
Hmmm, and I blamed sleep() all this time. How can this be?

I think, this means back to the drawing board?
Dmitri Christo
Ranch Hand

Joined: Jan 19, 2007
Posts: 81
..but the funny thing is that it does work with update(), when I add sleep() to the launching of the threads like this:


..Then with update() included, I have this output:


Now some more doubts arise:
1)Is this sleep() compromising the "randomness" of the spawning of the threads? This time it seems they are pretty sequential.
2)It is also strange that the execution halts in the same way (at update) if the sleep time in run is longer than the sleep time I put after Thread.start

Any wild guesses?
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
my wild guess is update...

do you interact with your hashmap inside your update ? Or any other "Member" variables ?

Regards,
Alex
Dmitri Christo
Ranch Hand

Joined: Jan 19, 2007
Posts: 81
Yes, I do a recordNumbers.get(recNo) to retrieve the location in file where the updated record is to be written.

And, of course, interact with the database file itself to perform the actual update.

I am not sure what you have in mind, could a flaw in this interaction cause the behavior I see during testing?

Thanks
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

It is not too easy to debug thread problems from a forum.
that's not the kind of problems I was seeking from your update, sorry or good job

I gotta say, I don't know...

To debug my threads, I executed it in debug mode, would keep 1 thread at a specific place and see how would react the other threads..

write down the different scenarios with 3 threads, and try them out with the debug.
That's as far as my advices can go here.

I'll welcome anyone else to help!

Regards,
Alex
[ February 12, 2008: Message edited by: Alex Belisle Turcot ]
Dmitri Christo
Ranch Hand

Joined: Jan 19, 2007
Posts: 81
Yes, I understand.. I was just hoping there'd be an obvious error, someone else could spot. But, like you said, its hard to tell if different behaviors are displayed.

I will need to re-visit some of the code for deeper debugging.

Thanks for your effort to help!
 
 
subject: testing concurrency and sleeping threads
 
Similar Threads
adding more threads
Can't Update Record ?
Note on Thread
JUnit Test Cases
problem with wait,notify