2

The platform for our application is Java 1.4.2. We need to run certain certification applications on this version of JVM (embedded system).

One of these applications is creating a thread T1 which updates a file (by writing to it) and another thread T2, which is supposed to read the updated contents(T2 is always launched after T1).

The problem is that the writing thread T1 is getting delayed and reading thread T2 is reading incorrect data. The thread T2 doesn't check whether contents of file were updated or not.

The delay causing factor can be assumed to be not fixable for the purposes of this discussion. We cannot change the application, but we can change the JVM and the native layer interface.

Please suggest solutions to serialize access to the file without changing the application. Also, please critique the following approach for feasibility: Create a look ahead thread in JVM which can analyze java byte code and serialize access to a file across multiple threads of the same application.

laalto
  • 150,114
  • 66
  • 286
  • 303
AquaAsh
  • 176
  • 1
  • 5
  • 12
  • 1
    This sounds like classic producer consumer problem. – Manish Oct 10 '13 at 06:33
  • 2
    You can' change the application but you can change the JVM, sorry that doesn't make sense as the JVM can change the application. You have a bug in your application and no amount of pretending you don't will work around the problem. If you can change the JVM, Consider using Java 7 as Java 1.4.2, Java 5.0 AND Java 6 are all end of life'd. – Peter Lawrey Oct 10 '13 at 06:33
  • Agree with @Manish, however if you have only two threads, one for writing and one for reading. Why don't you use Thread Join to make sure T2 gets joined to T1. – RaceBase Oct 10 '13 at 06:36
  • http://stackoverflow.com/questions/18444991/how-to-safely-publish-mutable-object-from-one-thread-to-another/ – Santosh Oct 10 '13 at 06:38
  • I think you would have better luck decompiling the program modifying it and recompiling it. Rather than trying some sort of byte code manipulation. – BevynQ Oct 10 '13 at 06:53

1 Answers1

1

please critique the following approach for feasibility: Create a look ahead thread in JVM which can analyze java byte code and serialize access to a file across multiple threads of the same application.

100% infeasible for the purposes of this discussion. If you can't do something as simple as upgrading a decade-old JVM and adding a bit of synchronization to the application that has been needed for just as long, you are going to be hopelessly out of your depth (a) modifying the JVM (b) adding threads to the application (I thought you said you couldn't modify it?) and (c) fiddling with bytecode, and (d) maintaining the resulting mess. Is the next guy going to be constrained to using the same 'modified' 1.4.2 JVM/added thread/generated bytecode? Where does this stop?

Instead you should be looking to really fix the problem. An application whose threads communicate among themselves via the filesystem has been badly misdesigned. Don't make it any worse.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • 1
    The java version to be used is a constraint, I have noted the system to be an embedded system in the original post. I meant adding a thread to JVM which can do a look ahead and analysis of code to be executed by some other threads. The application is part of a standard compliance testing disc and there is almost nil chance of having it modified. Guess I will try to fix the delay, though it was fixed earlier itself using a hack but apparently did not fix the issue completely. Thanks for your comments. – AquaAsh Oct 10 '13 at 08:37
  • I don't see how any of that changes anything. You have a decade-old system with what sounds like a decade-old bug. Adding 1000 crutches isn't going to improve things any. If you can change the JVM you can update it, and you don't have any practical choice but to fix the application at the same time. – user207421 Oct 10 '13 at 09:49
  • 1
    If certification application contains a bug, what is the sense to strive to pass it? Complain to the authority who issued it, they must fix it. If you change JVM, almost certainly you'll fail other tests. – Alexei Kaigorodov Oct 10 '13 at 19:22