Hi,
the problem was discussed here some time before. You need some atomic
operation, which cannot be successfully done by two processes at the
same time. One such operation is in most OSes (including Windows NT)
local file rename. Any operation on network drives (NetBios or NFS) is
not atomic, so you cannot rely on it when synchronizing multiple PCs -
file locking suggested by Brett Handley is reliable only with a local
file, not a file on a network disk.
I think that you should use TCP port on the server as suggested by
Brett Handley. There are also several distributed mutual exclusion
algorithms that don't require a central server, look at this paper for
more information:
http://www.cse.iitk.ac.in/~deepak/cs632/mutual-exclusion.ps
HTH,
--
Michal Kracik
"CRS - Psy Sel/SPO, COUSSEMENT Christophe, CPN" wrote:
>
> Hi REBOLians:
>
> I'm confronted with a little but important problem...
>
> I'm using a block structure for storing data on a server.
> 40 PC's -soon 80- could potentialy dump their data on the same time into one
> single data file on the server.
> Because we using Win NT -which I do not trust for reability-, I use a system
> of token to insure concurrent access to the file:
>
> <snip>
>
> forever [
> either all [(count<= 20) token?] [
> count: count + 1
> ;--- attempt to reserve token
> if error? err: try [write token-file now (true)][
> disarm err
> return false
> ]
> wait 5 ;--- take delay to be sure token is written
> ;--- try write operations
> answers: load local-file
> either error? err: try [save remote-file append load
> remote-file answers (true)][
> ;--- release token
> delete token-file
> disarm err
> return false
> ][
> ;--- release token
> delete token-file
> delete local-file
> return true
> ]
>
> ][
> return false
> ]
> ]
>
> token?: func [][
> return not exists? rejoin [global-answer-path global-token]
> ]
>
> </snip>
>
> The token is just a text file in this case, and gives the PC the right to
> "talk" to the server.
> The proc checks for the existence of a token on the server, for a maximum of
> 20 times. If there's no token on the server, it writes its own one, dump the
> data and release the token.
> Empirically, I had to set a delay of 5 sec to ensure the token is written,
> because of the slow network connection.
>
> Well, my question is not about straight REBOL, but more a matter of
> methodology :
>
> The procedure works, but, as you can imagine, it is not very efficient for
> so many PC working and dumping together.
> How can I achieve a better performence regarding concurrent access in REBOL
> on WinNT, which can garanty me no data will be lost ?
>
> Best regard,
>
> chr==
>
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
