Thread: Printing variables safely using printf, wprintw

I was interested to know if there is any process already in place to check variables when printing them using printf or wprintw.

Here is the scenario. There are variables being changed and altered in another thread. Then in another thread wprintw prints the contents of the variable to the screen terminal concurrently. Sometime the program segfaults randomly.
A hack (although I'm not sure if actually works) is to do a check like so:

Code:

wprintw(window, "%d\n", X ? X : 0);

Check if X is valid, but if not then output 0 instead.

Is this really necessary? Does this just test if X == 0 or does it test if X is an int?

Any knowledge greatly appreciated.

I have already debugged the problem and the problem lies somewhere in the ncurses (wprintw) implementation that I have done. Basically there are variables being updated in another thread and the ncurses wprintw lazily prints to term in another thread. It is possible wprintw is catching X in the middle of another atomic operation occurring on X from the other thread. The obvious solution is mutexs.

I would still like to know the answer to my original question. In printf what happens if the print function is called when the variable is not fully updated?

Second, what's the way to print variables in an absolutely lazy fashion without using mutexs or slow the program down?

Originally Posted by wiqxlzxsxj

I would still like to know the answer to my original question. In printf what happens if the print function is called when the variable is not fully updated?

I assume what you're asking is if it's possible for printf to actually segfault in that situation, which seems unlikely if all it's doing is accessing the value of an integer. It will just get the wrong value. It could only cause a segfault if it was used as an array index or something like that. If X is a pointer then obviously a bad value could cause a segfault.

If window is a pointer, you should check that it's value is good (not just non-null, but its proper value). Actually, even if it's an integer index into an array, or whatever, check it. Could it have been stomped somewhere?

It is possible wprintw is catching X in the middle of another atomic operation occurring on X from the other thread. The obvious solution is mutexs.

I don't see how that would be possible. Do you know what an "atomic operation" is? Kind of means the opposite.

Originally Posted by wiqxlzxsxj

I have already debugged the problem and the problem lies somewhere in the ncurses (wprintw) implementation that I have done. Basically there are variables being updated in another thread and the ncurses wprintw lazily prints to term in another thread. ...

If you are using threads, is your implementation of ncurses thread safe? I was not aware that there were any.

I am asking if printf will segfault? But by atomic I am referring to atomicity of a given operation in each mutually exclusive thread. So if X is being changed in the other thread and at the same, coincidentally, printf from another tries to read X what value of X will printf get if an int at all?

I understand there is a separate thread-safe implementation of ncurses. I'm using the standard -dev package.

If I alter my implementation slightly such that the ncurses window gets updated in series after X is modified (as you would in a single thread) then after a while the terminal starts getting incrementally garbled.

OK that's a fair enough explanation I was looking for. In terms of the assembly instructions, an int will always be an int.