GeeCON Prague 2014*
The moose likes Jobs Discussion and the fly likes java interview question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Careers » Jobs Discussion
Bookmark "java interview question" Watch "java interview question" New topic
Author

java interview question

pooja jain
greenhorn
Ranch Hand

Joined: Jan 12, 2005
Posts: 213
1. what if synchronized keyword is not there and we want to achieve synchoronization?

2. why its not recommended to catch run time exception? dont answer me that they occured due to programmer's mistake and so...


:d
Joe Ess
Bartender

Joined: Oct 29, 2001
Posts: 8913
    
    8

So what were your answers?


"blabbing like a narcissistic fool with a superiority complex" ~ N.A.
[How To Ask Questions On JavaRanch]
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Originally posted by pooja jain:
[QB]1. what if synchronized keyword is not there and we want to achieve synchoronization?
[QB]


One way could be:


[ January 17, 2008: Message edited by: ankur rathi ]
Gabriel Claramunt
Ranch Hand

Joined: May 26, 2007
Posts: 375
Hmm... and what happens if a second thread enters the "if(aThreadEntered)" before the first one executed "aThreadEntered = true;" ?
I don't think that you can implement synchronization without resorting to language locking primitives (probably if you use atomic variables, you can modify your example to make it work)
Originally posted by ankur rathi:


One way could be:



[ January 17, 2008: Message edited by: ankur rathi ]


Gabriel
Software Surgeon
Ayub ali khan
Ranch Hand

Joined: Oct 20, 2005
Posts: 380
    
    2
Hi,

I think if we define aThreadEntered as static is should work?

Regarding runtime exceptions..How many exceptions will you catch ? there might be number of possible runtime exceptions might be caught..

Regards
Ayub


SCEA part I,TOGAF Foundation
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830

Hmm... and what happens if a second thread enters the "if(aThreadEntered)" before the first one executed "aThreadEntered = true;" ?


I had recognized this issue in my code but I didn't find fix for it. So I posted the closest one I could get.


I think if we define aThreadEntered as static is should work?


Seems a good idea. Tough the above issue won�t solve with this but in case of two-instances-executing-this-code will work if we make it static.


Regarding runtime exceptions..How many exceptions will you catch ? there might be number of possible runtime exceptions might be caught..


You have an option of catching 'Exception'. :roll:
Alec Lee
Ranch Hand

Joined: Jan 28, 2004
Posts: 569
What about this strategy:

1. Create a dummy file in the filesystem named "unlocked"

2. every running thread try to RENAME the file to "locked.pid". (pid a unique id identifying the thread)

e.g. by issuing os shell command:
rename unlocked locked.pid

- this command is guaranteed to be atomic since a file cannot be of 2 names and once it is renamed another thread cannot rename it anymore since the 'unlocked' filename no longer exist and the 'rename' command simply fails

3. every thread check for the existence of a 'locked.pid' file where pid is its own unique id.

4. At the end, the thread having the 'lock' rename it back to 'unlocked'

5. Potential problem is if a thread exit without renaming the 'locked.pid' back to 'unlocked' all other threads cannot obtained the lock anymore.

This is the algorithm I designed (not tested) to achieve multi-tasking when I used a scripting language (Autoit3 - a window keystroke emulator) which doesn't have interprocess communication built-in.
Alec Lee
Ranch Hand

Joined: Jan 28, 2004
Posts: 569
Another idea is to obtain some OS provided resource which cannot be shared by 2 threads e.g. open a socket for a common port, open a common file in random write mode (reading and append mode not work), etc. The OS guarantees only 1 thread can obtain the resource and each thread just check if the target resource has been obtained by it before executing the synchronized code
Maris Orbidans
Ranch Hand

Joined: Mar 08, 2004
Posts: 149
1) use explicit locks



2) Because usually you can't recover from runtime exceptions. However you may want to catch runtime exceptions to write a message in a log file.
 
Don't get me started about those stupid light bulbs.
 
subject: java interview question