Prev: Have a question alike to 'sumif' in excel
Next: polar stereographic plot
From: Jan Simon on 16 Apr 2010 16:39
Dear Yair!

> Another poor-man's solution: try using the fileattrib function to test & set a specific file attribute (for example: archive or execute). It's not guarantied to be "thread-safe", but it should work in practice unless you have extremely close race conditions.

This is the first poor-man's solution from you, that I've seen.
But you are right: FILEATTRIB is better than EXIST('file') + FOPEN. Thanks!

A horrible side-effect of FILEATTRIB in Matlab 6.5 is the speed: it takes 0.2 sec even for accessing a file on the local harddrive.

I'll ask TMW for implementing a thread & network safe file mutex. I think, my problem should be quite common.

Jan
From: Walter Roberson on 16 Apr 2010 17:15
Jan Simon wrote:

> I'll ask TMW for implementing a thread & network safe file mutex. I
> think, my problem should be quite common.

I've only heard of it being successfully implemented on Token Ring networked
based filesystems, such as the old RFS (Apollo, 1983 time frame.) Even then I
don't know how they handled systems going down.

SGI's CXFS filesystem _claimed_ to have solved the problem for SANs (circa
1994), but we used to run CXFS here and I can assure you that it didn't solve
it :(

Some of the solutions I have heard of over time were more robust than others,
but they all had problems with network partitioning. The systems I've heard of
that "self-healed" after network partitioning required journaled updates (not
a problem in itself), and required that programs be "checkpointed" as of the
beginning of the first update whose complete distribution could not be
_proved_ -- it wasn't that the programs couldn't continue to run, but you had
to be able to "roll back" the execution of all shared accessors to the same
point so that you could resume the shared accesses from where you left off
(since the result of running shared sometimes *must* be different than the
result of running all the updates in sequence. Think, for example, bank
deposits and withdrawls.
From: Jan Simon on 17 Apr 2010 16:14
Dear Walter!

> Some of the solutions I have heard of over time were more robust than others,
> but they all had problems with network partitioning.

It sounds like I should stop working on a file system and use an ACID proof database.

Thanks, Jan
From: Walter Roberson on 17 Apr 2010 18:02
Jan Simon wrote:
> Dear Walter!

>> Some of the solutions I have heard of over time were more robust than
>> others, but they all had problems with network partitioning.

> It sounds like I should stop working on a file system and use an ACID
> proof database.

Yes, if you have multiple networked updaters to a single file and the
updaters have not been assigned specific offsets in the file (to avoid
overwriting each other), then you _are_ better off using a client/server
arrangement such as a database that uses a transaction file. Multiple
servers and fail-over is still an issue, but the reason to pay the big
bucks for database systems is that they have worked out the details.

Safe multi-client updates to a shared resource is indeed a common
request that sounds simple, but it is still open to a lot of rummination
by dining philosophers.
First  |  Prev  | 
Pages: 1 2
Prev: Have a question alike to 'sumif' in excel
Next: polar stereographic plot