LinuxQuestions.org - What is thread safe....???

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - What is thread safe....??? (https://www.linuxquestions.org/questions/programming-9/what-is-thread-safe-317273/)

What is thread safe....???

Hi all,
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....

With regard
RajSun.

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 */
err_sys("lseek error");
if (right(fd, buff, 100) != 100) /* and write */
err_sys("write error");

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:

Code:

#include <stdio.h>

#include <string.h>



int main(void)

{

  char str[] = "foo:bar";

  char *p;



  p = strtok(str, ":");

  while(p)

  {

    puts(p);

    p = strtok(NULL, ":");

  }

  return 0;

}

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:

Quote:

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
same string.
...
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.

I m thankful to u all.... for responding me in a very detailed way......

With Regard
RajSun

Any function which is thread safe, Can be called by many processes at time without affecting the private data of the other processes which r also useing the same function.