E*****l
发帖数: 2662 | 1
Usually what you should do for situation like this is to
design a class with mutually exclusive functions (use
synchronized prefix). All the file access should be implemented
in this class. In this way when a thread is doing something
to the file, no other thread can access the file. This may
not be what you want if you want to allow multiple threads
to read the file at the same time though. You can follow
the logic and design a class which allows multiple reads but
no read when writing is goin | o**d
发帖数: 11 | 2
I guess ditto try to prevent other program, instead of other
threads from accessing the file when it is written. Is it
right, ditto?
Synchronized method can claim lock on the object, but that
lock is only valid to the thread within the same
application.
My solution is to create a temp file in the system temp
directory. After finished writing, rename it.
I don't like global variable and there is no such thing in
Java( Probably you can simulate it). Besides, this solution
only works when the to-b
【在 E*****l 的大作中提到】
:
: Usually what you should do for situation like this is to
: design a class with mutually exclusive functions (use
: synchronized prefix). All the file access should be implemented
: in this class. In this way when a thread is doing something
: to the file, no other thread can access the file. This may
: not be what you want if you want to allow multiple threads
: to read the file at the same time though. You can follow
: the logic and design a class which allows multiple reads but
: no read when writing is goin
| m******t
发帖数: 2416 | 3
This one suffers the same pitfall that you just pointed out
for his solution to the second problem. 8-)
Whether there is a satisfying answer to ditto's question relying
on whether he needs a cooperative or mandatory locking.
Here is some "strategy guide" from Sun (go to question 6):
http://java.sun.com/people/linden/faq_b2.html
【在 o**d 的大作中提到】
:
: I guess ditto try to prevent other program, instead of other
: threads from accessing the file when it is written. Is it
: right, ditto?
: Synchronized method can claim lock on the object, but that
: lock is only valid to the thread within the same
: application.
: My solution is to create a temp file in the system temp
: directory. After finished writing, rename it.
: I don't like global variable and there is no such thing in
| m******t
发帖数: 2416 | 4
Hmmm what I was trying to say is to use a temp file to "flag"
the locking status would have the same drawback as to use a global
variable to check whether a thread is still alive. That is,
if the program currently holding the lock fails to delete the
"flag file" before it exits, there will be deadlock.
【在 o**d 的大作中提到】
:
: I guess ditto try to prevent other program, instead of other
: threads from accessing the file when it is written. Is it
: right, ditto?
: Synchronized method can claim lock on the object, but that
: lock is only valid to the thread within the same
: application.
: My solution is to create a temp file in the system temp
: directory. After finished writing, rename it.
: I don't like global variable and there is no such thing in
| o**d
发帖数: 11 | 5
I see what you mean. But I am not saying using the temp
file as a "flag". Even you use something as a flag, you can
not prevent some other application from deleting it. That
flag is still within your application. Other
application/program will not check your flag first.
The original quesiton is how to "prevent other programs from
touching it, even read it".
My solution doesn't use flag. The temp file is the file we
will write the real content to. Making it a temp file in the
system temp dir an
【在 m******t 的大作中提到】
:
: Hmmm what I was trying to say is to use a temp file to "flag"
: the locking status would have the same drawback as to use a global
: variable to check whether a thread is still alive. That is,
: if the program currently holding the lock fails to delete the
: "flag file" before it exits, there will be deadlock.
|
|
