Hi Ladislav,
sorry, I looked at it and it is atomic in both NFS and SMB. Next time
I'll check before confusing anyone. Still there's a possibility that a
client does not know that it succeeded or failed if the reply is lost
and the connection time-outs. After the connection is re-estabilished,
recovery should consider this situation, but that can happen even with
a local file when power fails at the "right" time.
Regards,
--
Michal Kracik
Ladislav Mecir wrote:
>
> Hi Michal,
>
> Did I understand correctly, that RENAME is not an atomic operation for
> network drives?
>
> Regards
> Ladislav
>
> > 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.
> >
> >
>
> --
> 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.
