• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

java interview question

 
pooja jain
greenhorn
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
Joe Ess
Bartender
Posts: 9320
10
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So what were your answers?
 
ankur rathi
Ranch Hand
Posts: 3830
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 375
Monad Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Ayub ali khan
Ranch Hand
Posts: 394
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
ankur rathi
Ranch Hand
Posts: 3830
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 569
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 569
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 149
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic