ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Can any body tell me waht is thread safe library...???
What really does it mean...???
If possible plz let me know from where i can get more information on thread safe library...???
So that i can write thread safe codes and libraries....
In Linux a thread is a process. However, the difference is that threads can share memory. You can have a program that has started 4 separate child threads. Each thread has it's own virtual CPU but the threads share the VM (Virtual Memory). Now if you have a variable being updated by the first thread, but in the process, the second thread is started and it reads that variable, the value is invalid because only part of it was changed. There are several mechanisms to protect against this. One is to use 'atomic' functions. They will complete before a task switch.
Perhaps an example is in order. Suppose you have code in your library to append data to a file. It used to be done like this:
if (lseek(fd, 0L, 2) < 0) /* positing to EOF */
if (right(fd, buff, 100) != 100) /* and write */
This would work with only one thread. However, if two threads are trying to append to the file (such as is the case with log files) and a task-switch takes place after the first instruction, then the second process will append to the end of the file, but when the it's the first processes turn, it will start writing at the old EOF position, overwriting what the second process wrote.
This is why the O_APPEND flag was added as an option to the open() function.
Other things like the _POSIX_PIPE_BUF ( the number of bytes that can be written to a pipe) have to be considered also. Whenever to process or threads or CPU's can access the same data, this is known as a "critical region". Either the operation has to be done atomically, or the first thread has to set a lock on the data. In other words, the lock is code that precedes the data access. If another thread is still changing the data, the new thread has to wait until the lock is released. For a MP system, it would be to expensive to have to wait for a task change to resume, so "spin locks" are used instead. The second thread executes a tight loop until the lock is released by the other thread.
It is not just libraries, but any program that runs more than one thread, needs to have shared resources protected. A thread safe library is a library that you can use in such a program.
Thread-safe libraries don't need to maintain any internal information between calls. For instance, look at this program:
char str = "foo:bar";
p = strtok(str, ":");
p = strtok(NULL, ":");
strtok() keeps a copy of the string internally so the next time you call strtok() with NULL as the first argument it knows to find the next substring. This is not threadsafe because if another thread calls strtok() it will overwrite its internal buffer and then the first thread will be all screwed up. glibc offers a thread-safe version of strtok() by allocating memory dynamically for its internal buffer rather than using a static buffer. The man page explains it like this:
The strtok_r() function works the same as the strtok()
function, but instead of using a static buffer it uses a
pointer to a user allocated char* pointer. This pointer,
the ptrptr parameter, must be the same while parsing the
The strtok() function uses a static buffer while
parsing, so it's not thread safe. Use strtok_r() if
this matters to you.
The other item that is EXTREMELY important in writing thread-safe libraries is something that itsme86 touched on - namely the usage of internal vs. external variables. It is absolutely vital that you either rely on internal variables that make use of the stack for your variables or that you safeguard access to any external or global data variables. Remember, multi-threading allows shared access to global data. This means that without some sort of protection (semaphores, or mutex locks) there is nothing to prevent one thread from changing a global variable while another thread was in the process of using it. The simplest way of writing thread-safe functions is to make sure that you do not rely on any external or global data variables, and that all of your variables are declared using the stack. That way when the function is invoked, it will receive it's own private versions of the data variables and calling it multiple times (or recursively) will not cause things to change in a seemingly random way.