While running the program floath.C on various machines which perform arithmetic on other than IEEE style, I have found a few improvements to be made. The most serious problem occurs in the first loop, labeled in the comment "find smallest power of 2 . . "where the relational >= should be changed to ==. The expression to the left of == evaluates as 1 until the last time through the loop, when it becomes 0 on most machines, including those which have IEEE style rounding. With DEC style rounding, the expression rounds up to 2 at the end of the loop. If the loop is continued, with either rounding behavior, the expression evaluates to 0 until an overflow occurs. The loop as published ran one time too often on DEC-like machines, causing the erroneous report of a radix of 4. The change will enable the loop to work also with interval arithmetic rounding modes.

The expression for division rounding is not reliable on a machine where subtraction is not properly guarded. As far as I know, there are no such machines remaining on the market. The problem can be cured by setting

v = l - z;

Ecosoft's 8-bit software floating point subtraction arbitrarily sets the result to 0 when evaluating expression such as

1 - (1 - DBL_EPSILON*.5)

I apologize for inconvenience which may have been caused by the lack of claimed generality in the code, and appreciate any information which may be turned up by running it on other systems, even museum pieces.

Sincerely yours,

Tim Prince
39 Harbor Hill Rd.
Grosse Pte Farms, MI 48236

Dear Mr. Ward,

I would like to congratulate Mr. Frost on his excellent article describing the use of files as semaphores ("Using Files as Semaphores", CUJ, April 1990). This is a topic which has long been neglected and I was quite pleased to see your magazine's coverage of the topic. Having implemented a mechanism very similar to the one described by Mr. Frost, I feel a few points require rebuttal.

When the existence of a file is used for resource locking, there are two primary problems, the first revolves around the performance of constantly creating and deleting files. Although operating system performance vis-a-vis the file system is being enhanced on many platforms, it is still one of the slower parts of the environment. Thus, repeated file creation and deletion can result in unacceptable performance degradation. Secondly, while operating systems such as UNIX will automatically remove a semaphore file, other systems (DOS for example) will not do so. Thus, on a system without autodeletion of semaphore files, if your program terminates abnormally for any reason, any locked resources may remain inaccessible to other processes.

When I began designing a semaphore mechanism for my employer, the following requirements were outlined: 1) access to a fixed number of shareable resources were to be managed independently by the mechanism (a total of 19 resources eventually), 2) multiple, simultaneous "read" operations were to be permitted on any resource, 3) a single "append" operation was to be permitted to occur on a resource while "reads" were occurring, 4) a single "write" operation could commence only after all active "append" and "read" operations were completed for a resource. In this context, a "write" operation entailed overwriting data which already existed in the resource. Finally, the software being developed was to be ported from the original Xenix system, to UNIX, DOS (3.1 +), VAX/VMS and the Macintosh.

It was obvious early in the design state that a file-based resource sharing mechanism would be maximally portable since DOS and the Mac do not offer shared memory or in-memory semaphores as Xenix and UNIX do. As outlined previously, creating and deleting semaphore files was not an acceptable solution for performance reasons. The following scheme was eventually settled upon and is now in use on three platforms.

A single file is used and contains 3 bytes for each of the resources (3*19=57 bytes). Each byte has a special purpose for the resource. Byte 1 is the "write" semaphore, byte 2 is the "read" semaphore and byte 3 is the "append" semaphore. In order to gain access to a resource, a process locks these bytes. Using file locks as the following benefit: abnormal program terminations (power failure, control-c, kill signal,...) do not block further access to the resource because the operating system guarantees that all locks held by the process are removed when the file is closed (i.e. at process termination).

In order to access the "semaphore" set contained in the file, a process merely opens the file. This is generally done as part of the program startup with the file being closed at termination. Once access is gained to the file, the following steps are required in order to gain access to a particular resource.

2) lock the resource's "read" byte for shared access (if the op.sys. permits shared locks otherwise, use an exclusive lock)

3) unlock the resource's "write" byte

4) read the data from the resource

5) unlock the resource's "read" byte

2) lock the resource's "write" byte for exclusive access

3) unlock the resource's "write" byte

4) extend the resource by appending new data to the end

5) unlock the resource's "append" byte

2) lock the resource's "write" byte for exclusive access

3) lock the resource's "read" byte for exclusive access

4) write a non-zero value to the resource's "write" byte

5) write data to the resource

6) write a zero value to the resource's "write" byte

7) unlock the resource's "read" byte

8) unlock the resource's "write" byte

9) unlock the resource's "append" byte

Whenever the "write" byte is locked, a test is made whether a previous transaction has failed before completion. If failure has occurred, the resource in question may be corrupted and a "rollback" of the transaction is executed. A failed transaction is indicated by the value stored in the "write" byte being non-zero. This can only occur if step 4 was executed without the complementary step 6 occuring. This mechanism is quite similar to the "readers and writers" mechanism Mr. Frost describes. However, it is important to remember that the count variable used to track the number of concurrent reads MUST be accessible to every user of the resource. The operating system's file locking mechanism is used for this purpose.

Russell Cook
Software Engineer
ZyLAB Corpoation
3105-T North Wilke
Arlington Heights, IL 60004

I think it's great to get this kind of exchange between programmers who have implemented separate solutions to a similar problem. Thanks for contributing. —rlw

Dear Editor:

First let me say thank you for providing an excellent magazine. It's the only one that I make time to read cover to cover. I've even gone back and re-read articles several times to squeeze all the good parts out.

I would like to recommend to anyone who is programming computers who is not using UNIX, should try it at least once. Talk about heaven. I thought C was wonderful coming from a background of BASIC and assembly. UNIX is to MS-DOS as C is to BASIC.

Do you have any suggestions for good basic UNIX books that don't get stuck in low gear? I'm having trouble finding basic information about UNIX. It appears as though I find something new every day, and really could have used that information yesterday.

In Sydney Weinstein's article "Games and Tongues" (vol. 8, no. 2), he mentioned a game called Conquer. He also said it is available from archive sites for comp.sources.games, including uunet. I would like to know how to get this or other UNIX programs from somewhere, either disk or modem. If it is through the modem, could you give some hints or instructions on how to do this? I am familiar with downloading programs using MS-DOS type environments.

Thank you for all the support

Kenneth J. Suda
P.O. Box 507
Canton, GA 30114

UNIX software is usually exchanged via uucp facilities — i.e. you must be "attached" to USENET. You can find fundamental information about USENET in UNIX Communications by The Waite Group. UNIX System Administration by David Fiedler and Bruce Hunter includes quite a bit of very useful information about how to get attached to USENET and how to configure your system.

Some books that don't get "stuck":

Advanced Programmer's Guide to UNIX System V by Thomas, Rogers and Yates. Tricks of the UNIX Masters by Sage. UNIX for Super-Users by Foxley. The UNIX System V Environment by Bourne. And just for fun, Writing A UNIX Device Driver by Egan and Teixeira. —rlw

The following discrepancies have been noted in the source code for cstr. c which appeared in The C Users Journal, February 1989, page 28-29:

1. The header file blstr. h was not included with the code.

2. The macro error() was not defined.

3. The error message when the output file can not be opened stated that "Can't open %s for input \n". "output" should be substituted for "input".

4. String functions are included in the header file <string.h>. This file was not included in the source code.

5. The string function strbreak does not appear to be a standard function. The string function strpbrk which I believe serves the same purpose is a standard function and is contained in Turbo C, Microsoft C, Lattice C at least.

6. The arguments of strcmp are character pointers. The source code for function makeout contains *in, which contains the value of the character pointed to by in.

7. The accompanying documentation for cstr.c does not point out how cstruse.c is to be obtained. In usage (), I commented out the two lines of code dealing with cstruse[], and then compiled, linked and ran the program with the text file cstruse.str identified on the command line. Once cstruse[] was created by cstr.exe and contained in cstruse.c, I uncommented the cstruse[] code lines in usage (), appended cstruse.c to cstr.c, recompiled, linked and then successfully ran the program.