I enjoyed reading your article on pointers. I found it very informative. However, I'm having trouble completely understanding it. Is there a way to cause a core dump in C? I use Borland's C++ and I feel if I could see the addresses and their contents I would have a fuller understanding. Perhaps core dumps could be a new topic for another article. Thank you.

Sincerely,

Michael Anderson
P.O. Box 222304
Chantilly, VA 22022

As a refugee from the days of multipage core dumps, I can assure you that they get old real quick. Have you fired up Borland's debugger yet? I suspect that a few days of poking around with it will be far more educational than a raw core dump. — pjp

Dear Sir:

This letter has been written in response to the paper titled "Making C++ Safe for Threads" by Dave Plauger in your February, 1993 issue. The opinions expressed in this letter are the author's opinions, and are not necessarily those of his employer.

The overall theme of the paper is that threads should avoid cooperation and do things in a thread-specific manner to gain performance. I believe that one of the prime reasons for threads is to improve cooperation between computational entities (processes or threads). Advising readers to increase the amount of information specific to a thread increases the "weight" of the thread. It moves the thread back towards the "weight" of processes. We've gone through this effort to get threads to decrease the "weight." After all, threads used to be called "lightweight processes." Let's keep the thoughts about threads lightweight.

The streams part of libC is an example of this. By making the streams specific to a thread decreases the amount of cooperation between threads. From the paper, I was unable to decide whether two threads could read a common stream. I think that the underlying streambuf will buffer the input, thus making it impossible for different threads to cooperate in reading the input. Making streams thread-specific decreases cooperation.

The solution to making streams MT-safe is not complete. While it may capture some usage patterns for streams, it clearly does not cover the entire range of uses. Issues like sharing streambufs between streams and using implementation inheritance in one of the stream classes are not covered.

Another main theme is about performance. In general, it is wise to avoid premature optimization. There is the assumption that acquiring a lock is expensive. In my experience, most threads systems optimize locking and it is not very expensive. But like any facility it can be misused, so that locking in the "inner loop" should usually be avoided.

The paper recognizes only one reason for threads: for speed up of applications (p.58). While this is one valid use of threads, there are many other reasons to use threads. Threads can be used to structure software so that it is more modular. Threads can be used to improve apparent availability of an application. Threads can be used to deal with blocking.

The paper states that "Locks should be associated with data, not code" (p. 59). The reason given is performance. Program structuring, ease of debugging, and simplicity of modification may be better with code rather than data locks. Code locks (a critical section) are easier to understand and get right. Both code and data locks should be used. It is a design and optimization decision. There is not a general, simple rule.

There is a small error in the following statement: "... all automatic variables are thread-safe" (p. 59). Pointers to automatic variables may be passed between threads. In this case, not only is the variable itself not thread-safe, but there is the concern for the lifetime of the variable.

Performance again appears in the following advice (p. 59): "It's best to make variables thread-private whenever possible. The access cost of thread-specific data is much less compared to lock/unlock overhead, ..." This statement is not true for all threads systems. Locking is heavily optimized and can be faster than access to thread-specific storage.

When discussing optimizations, the paper states (p. 59-60):

"... For example, a Boolean variable used as a flag can be set or cleared without synchronization. The code sequence:

lock;
flag=1;
unlock;

If the point of the code is to notify other threads of the setting of the flag, then the locking is required. The memory model of many computers will not guarantee that other threads reading "flag" after its setting will see the new value. Without the locking, the code would not be portable. In the next draft of the POSIX threads standard (D7) there will be a section on Memory Models (most likely in Sections 2.8 and 2.9). The above code will be disallowed in the new sections.

I found the description of the streams inadequate. I could not determine whether there was one underlying "global stream" for each standard VO stream, or whether there was a stream per thread, or whether there were both. If there is a global stream, then access to it must be synchronized at the stream layer to keep it safe. If there are only private streams, then reading and writing have undesirable semantics. As mentioned above, reading from cin will buffer in the private stream, so in effect only one thread can ever read cin. Writing to cout must be coordinated and flushes done during synchronization.

Sincerely,

Dr. Robert Hagmann
2550 Garcia Ave.
Mountain View, CA
robert.hagmann@Eng.Sun.Com

There seem to be about as many opinions about how best to implement and use threads as there are implementers and users. Threads are indeed an important structuring tool in an environment that can profit from (and support) multiple loci of control. My personal experience is that the areas of cooperation must be as narrow and as clearly delineated as possible, lest surprising race conditions haunt your debugging hours. Sharing I/0 streams between threads is generally the last on my list of desirable ways to cooperate. Making streams mostly thread private is a good idea both for performance and partitioning.

But as I indicated at the outset, tastes vary. — pjp

Dear Dr. Plauger.

Is C a Language? It may be misleading but the point isn't. As a long time reader of your magazine I have to say I find it very informative. I am a C programming hobbyist. It may sound odd. I once heard a definition of programming as "Engaging in a pastime similar to banging one's head against the wall, but with fewer opportunities for reward," which brings me to the problem.

Where does a moderately advanced programmer turn to learn the "How to's" and the "This is the why we do it this way" of using C? I mean, if you walk into a bookstore or read any C programming magazine you either come across beginning or advanced books/ articles of the dictionary/grammar type. There doesn't appear to be anywhere for the mid-level programmer in C to turn to find an article or book which steps back a bit giving a C program version of "How to write the short story." Why?

I would appreciate a column in your magazine that is less specific than your Standard C column. A step or two back if you will. One that gives the thinking behind an implementation and the choices possible. A column a mid-level programmer could read and can see how to implement features into a program with professional results. Providing the why it would be done one way and not another approach.

Example: The various ways in which a programmer can provide a user selectable color for the screens in his program without getting specific and at the coding level. What to look for by way of traps and why one way is better under certain circumstances than another. Breaking down a professional level program in this manner I feel would be quite beneficial.

I must have 70+ books on C programming on my bookshelves and have yet to find one in which this approach is taken. All touch on it just enough to whet your appetite to buy the book in the bookstore but disappoint after the closer examination at home. I can find no magazines which use this approach. Your Standard C column comes the closest. Yet the same bookstores have racks upon racks of "How to write articles for television" or "How to write short stories" type books in English, Spanish, or German!

Which brings me back to the beginning. Is C a Language and if so when will someone start showing us more than the grammar and dictionary portions of it?

Sincerely,

Mike Musielski
16 Academy Rd.
Madison, NJ 07940

Gerry Weinberg observed many years ago that our approach to teaching programming could take a page or two from how English is taught. You, like he, are basically asking for a body of literature to study — perhaps even an occasional creative writing course. That need is much better met today, with all the good books and magazines, than even ten years ago. Still, we all have a long way to go. We at The C Users Journal will keep trying to provide good literature for C and C+ + programmers. — pjp

Dear Sir,

I just received my first issue of CUJ two days ago. I was immediately struck by the typo on the cover — definitely, this magazine surely isn't like the others. A good omen, as long as the listings don't have typos.

Indeed it isn't — this one is useful. So I hope you will forgive my excessively enthusiastic letter (it will pass, it will pass.)

I share Mr. Ludger Engbert's fury towards software support, namely the bad news about the Turbo C 2.0 library source code, which I intended to purchase myself. It's not a new behavior, as I am used to getting no support at all. Software vendors seem to sell their products as if they were selling used cars or the like; there's a promise list, but that's just as far as it goes. You bought it, now it's your problem. Caveat emptor.

As an example, I had a problem related with Turbo C 2.0 and duly consulted Borland Europe Technical Support in France, which the locals there call Borland France Technical Support. (I hope this may be corrected in the next issues of Borland's handbooks, so that they don't fool themselves and us into thinking there may be technical support for Europe through Borland's French office) The French told me to contact the retailer for Portugal, which I did. By phone, naturally. Answer: Huh... We're afraid nobody knows C here, but send us your problem in English and we'll fax it to the US. Great. At least they show some good will.

As another example, I tried to obtain some piece of software from Microsoft Portugal. I was referred to two retailers, to which I requested the software last July. I didn't even receive a reply. I'm looking for that piece of software since 1990.

The bottom line is, obviously, that it becomes thus pointless to buy legal software (here), as you are paying for something you won't get: support. You just copy it and you'll have the same status as the dumb legal buyer, such as me; that is, none. Either the legal buyer has a real edge over the common copier or one had better copy that floppy. Why show consideration for software vendors if that consideration doesn't go both ways? Not that I like this state of affairs.

On Mr. Andy Levinson's letter, the only thing I would add is that using MS-DOS is a real pain; I especially love the lack of documentation. But if you want to develop software for the people, you're bound to it. I keep a vivid and happy memory of the six months during which I had access to a UNIX system some five years ago.

Mr. Ross's reply to Mr. Grammas suggests that Mr. Ross forgot a couple of comment lines in his code, fortunately now documented with two paragraphs of explanation. If Mr. Grammas wrongly assumed something, and doesn't see another, it might be that Mr. Ross's code isn't readable enough. Matters of personal style. Such as with the virtuoso Paganini, who only wrote down some reminders of his concerti's musical score, just for himself, as he had the rest in his head. We have long quit on trying to guess how and what Paganini actually played on his fiddle. I have been more than once hurt (as everyone, I suppose) in these C flying trapeze acrobatics with pointers and find it a tremendous bore to bring the whole shebang back up from successive crashes again and again, and have neither Mr. Ross's boldness nor mastery. I rather understand Mr. Grammas' waryness about null terminators and other wild things.

If CUJ intends to keep this sort of forum for open debate I must say it may quite be the most refreshing publication I ever found so far.

Best regards.

Yours truly,

Prof. Dr. Joao C. de Magalhaes, D. M. Sc.
R. Almeida Garrett 16 5E
Carnaxide
2795 Linda-A-Velha
Portugal

Dear Mr Plauger,

My apologies for bothering you. I am an undergraduate student at the University of Wisconsin-Superior, Majoring in Math with Computer Science option. I am a constant reader of CUJ. In the April issue (Vol 11, No 4), the article "A Natural Language Processor" by Russel Suereth was pretty good!

I tried to compile the code listed, but our compiler says its missing a function. I have no clue how to debug this, but my curiosity is killing me. It would be great if I can get it to run. Please help, if you can.

We have HPUX Release 8.0 (HP 9000 series). The error is that the compiler couldn't find strcmpi (code). I hope this information is sufficient.

Thanks in Advance,

Yohendran Arumainayagam (YoGi!)
University of Wisconsin - Superior
UWS Box 324
1600 Catlin Ave.
Superior, WI 54880-6699
yarumain@hp. uwsuper. edu

Russell Suereth replies:

Dear Mr. Arumainayagam:

The strcmpi function is a string compare function that is very similar to strcmp. The difference between these two functions is that strcmpi is case insensitive while strcmp is case sensitive.

Some compilers include strcmpi in their libraries. My error was that strcmpi is not in the ISO and ANSI C Standard library. Thanks for finding this oversight.

You can create your own strcmpi function. Pass the two strings to the function and use toupper to change the strings to upper case. Use the strcmp function to compare the upper case strings. The returned value of strcmp is the returned value of your strcmpi function. Remember that toupper changes the original string, so change a copy of the string rather than the original. This version of strcmpi is not perfect but should work in most contexts.

Thank you.

Russell Suereth

Mr. Plauger:

This letter has a twofold purpose: to tell you how much I enjoy my subscription to the Journal but also to appeal for help, I have read every book and article I can get my hands on (including yours) and am stumped on coming up with a certain algorithm.

Here are the details. I use my computer, and write most of my own programs, to analyze sports at every level. However, whenever I cannot write the necessary program that will save me valuable time, I am forced to use a spreadsheet. I get cramped when seasons overlap. A specific example is this: If I have a list of items, say points scored in a league of football teams, team by team, I need first to arrange the totals from highest to lowest. Then divide the highest number into itself and multiply by 100 to show it as "100%", or the best among that group of teams (parity being what it is). Next, each subsequent number in the list needs to be divided by that same highest number and multiplied by 100 to show how it compares. Example: if a team has 100 cumulative points and the next one on the list has 82, they need to be expressed as 100 and 82 "percentage points" respectively and so on down the list until all have been processed in this manner.

On the face of it, this method is relatively simple (and eliminates the inherent risks of working with ever-increasing larger numbers) but is accurate if manipulated correctly. (Do I use an array or random file?) By using it in conjunction with some other team statistics, I correctly predicted five of the eventual state champions in Texas schoolboy football. A sample copy of my newsletter is enclosed. ("SC" denotes state champion while the asterisk signifies playoff contenders. )

If you would, please treat this in some upcoming article in "The C Users Journal" or turn it over to someone who can furnish this information. I am certain there are other readers who have the same or similar questions and needs and this will be greatly appreciated. In any event, I have enclosed a stamped self-addressed envelope so you may let me know what to expect. Additionally, if anyone has questions about my methods, I will be willing to share information.

Thank you,

Drew Matthews
Texas Sports Index Service
P.O. Box 384
Comfort, TX
78013-0394

Sounds to me like you're still wrestling with some of the basic issues of C programming. I'd keep my programming efforts modest — like working just with arrays of data in memory instead of with arbitrary length files — until you get more of the idioms down. — pjp