Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 12 Aug 2001 03:24:24 -0400
From:      "Andrew C. Hornback" <achornback@worldnet.att.net>
To:        "Jules Gilbert" <jules@aasp.net>, <freebsd-questions@FreeBSD.ORG>
Cc:        <jg@medg.lcs.mit.edu>
Subject:   RE: simple, stupid question...
Message-ID:  <007501c122ff$cff79a40$0e00000a@tomcat>
In-Reply-To: <3B762E90.E9DCF329@aasp.net>

next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message-----
> From: owner-freebsd-questions@FreeBSD.ORG
> [mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of Jules Gilbert
> Sent: Sunday, August 12, 2001 3:22 AM
> To: freebsd-questions@FreeBSD.ORG
> Subject: simple, stupid question...
>
>
> I am not a BSD whiz.

	Makes two of us... *grins*

> But I have a bunch of BSD systems which run all the time, and
> occasionally one of them comes up with a bright idea 'he' wants to write
> to a common file on one of the machines.  That way I can see it in the
> morning.
>
> Now, the thing is, it could happen that two machines attempt to do an
> 'fopen' concurrently, with the second argument being "ab", ie., append
> binary.
>
> All machines talk to a common directory (which exists on a single
> machine) over an NFS based architecture.   These machines spend most of
> their time thinking.  I was considering allowing each machine a small
> slot of time, so that a deadlock on the common resource would be
> impossible.
>
> (First machine gets the first 10 seconds of a minute.  Second machine
> gets the second 10 seconds of a minute, etc...)    These machines spend
> most of their life thinking deep thoughts and only occasionally want to
> write to this single file on one directory on one of the machines, so
> the chance for collisions is small anyway...
>
> Another way is to cause one machine to successfully open the file, write
> out the brilliance, and the other machine to be told to try back in 30
> seconds or a minute.

	Okay, back in the day, we used to call something like this "file
semaphoring".  Basically, when a machine opens a file, it drops a semaphore
(another simple text or binary file) while it has that file open and deletes
the semaphore when the file is closed.  When another machine goes to write
to this file, they check for a semaphore (basically saying that the file is
either in use or it isn't) and if there's no semaphore, they send their own
and open the file.  This could also have the added benefit of telling you
when a machine has the file open, and which machine (if you give each
machine it's own special identifier semaphore file).

	I think this is what you're looking to implement here.

	I'm not too familiar with NFS, but there might be a way to do this from an
NFS client as opposed to having to write code to do it.

> Is a file lock (flock.tar), the right choice here?  Years ago, I used a
> machine which had two macros, "ENQUE" and "DEQUE", which by naming the
> resource, assured me of serial access.  (The thing is, it didn't always
> work.  This was the Xerox Sigma 9;  over 10,000 years ago...)
>
> Also, any advantage to using text files here instead of binary files,
> with respect to this problem?

	I don't think that this should really matter, since, from what I get out of
your e-mail, each machine is going to be only writing to the file to show
their results as opposed to having to read it.  The only time that the file
would need to be read is in order to determine where the next string of data
should go, which can be easily accomplished using either binary or text
files.

> Please copy your answer to:  jules@aasp.net and also me as:
> jg@medg.lcs.mit.edu
>
> By the way, THANK YOU BSD COMMUNITY  -- this is a wonderful system, and
> while I am still learning how to best make use of it, I, along with
> thousands of others living on this planet, thank you for your efforts.
> This ingredient, among others, enables me to make a living without
> having to use/touch/feel/see/think about MS and that whole ugly mess...

	Eh, some of us used to make a living off of cleaning up after MS and that
whole ugly mess... *grins*

--- Andy


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?007501c122ff$cff79a40$0e00000a>