In comp.os.linux.advocacy, Ray Ingles
<sorceror@xxxxxxxxxxxxxxxxxxxxx>
wrote
on 13 Jun 2006 09:06:35 -0400
<slrne8tegh.j4p.sorceror@xxxxxxxxxxxxxxxxxxxxx>:
> On 2006-06-13, Tim Smith <reply_in_group@xxxxxxxxxxxxxxxx> wrote:
>> If your architecture really needs mandatory locks, then you have to
>> seriously consider whether it might make more sense to run on Windows.
>
> If your architecture requires mandatory locks at the filesystem level,
> I'd have to wonder about your architecture. I haven't run into a
> situation that needed that in, well, ever. Can you provide a real-world
> example?
>
I'll admit to wondering as well. If there *is* a lock it
should be as transient as possible.
A simple "application" is installing a bit o' software over
another version -- ignoring such issues as symbolic link
version naming (e.g.
libgthread-2.0.so -> libgthread-2.0.so.0.800.6,
libgthread-2.0.so.0 -> libgthread-2.0.so.0.800.6).
For example upgrading libz.so is as simple as:
[1] Unpack.
[2] Build.
[3] Install using /usr/bin/install. I'll admit to some
curiosity as to whether install does it entirely
right, as I'd simply move the new file into place
after copying it to a temporary location guaranteed
to be in the same file system.
[4] Use.
The lock, in this case, would be on the directory holding
the file; an inode needs to be changed in a file entry when
one renames a file over another. It's a very short lock, and
usually unseen by the casual user.
(Admittedly libz is really a little too simple as a good example.)
It's getting better in Windows, but Windows has some
issues, because of their slightly brain-dead locking
scheme. (Apparently part of the issue is the lack of
internal inodes in FAT32 and in NTFS. FAT32 might have
inodes of a sort: cluster numbers. It's not quite the
same.)
[1] Unpack.
[2] Build.
[3] Oops, can't copy some files as the files are locked; put
the files in a special place and wiggle the registry.
[4] Reboot, a highly disruptive procedure that takes several
minutes.
[5] Shortly after the reboot, the registry tells the OS to
copy the files into where they're supposed to go.
[6] Get back to where you were prior to the reboot. Some
apps might helpfully open their windows for you upon login. (This
actually is something Linux/X could use better support in,
though most of the hooks are there in the session and window
managers. It's not a very pressing problem, though.)
[7] Use.
Now in some cases -- only some, mind you -- Windows can do
the first procedure, if the application is such that it can
be guaranteed quiescent and no files are locked. However,
I don't know if Windows XP still caches DLL information
explicitly, or not. (AFAIK, Linux doesn't bother;
the caching is handled at the inode and page level.)
Since DLL caching locks the DLL (it has to open it for
read, after all, and Windows presumably leaves it open
so that nothing else can corrupt it while it's in use --
a problem that plagued HP-UX for awhile, version 8 or so;
HP-UX inelegantly crashed the app with a page I/O error),
caching DLLs leads to some annoying scenarios.
If there's a "DLL cache flush", I don't know of it.
Mandatory locks might be useful for databases but a better
architecture might simply be single-threading the problem.
However, I'd have to look to see how PostgreSQL does it.
Traditionally, X single-threaded the drawing problem for
many years, and probably still does for non-OpenGL stuff.
--
#191, ewill3@xxxxxxxxxxxxx
Windows Vista. Because it's time to refresh your hardware. Trust us.
|
|
