rand_r是否是真实的线程安全的？ [英] whether rand_r is real thread safe?

问题描述

那么，rand_r功能应该是一个线程安全的功能。然而，它的实现，我不能相信它可以使自己不被其他线程改变。
假设两个线程在同一时间以相同的变量调用的种子rand_r。
所以会发生读写比赛。
由glibc的实现的code rand_r如下。任何人都知道为什么rand_r被称为线程安全的？

  INT
    rand_r（无符号整数*种子）
    {
      unsigned int类型下一= *种子;
      INT结果;      下一个* = 1103515245;
      接下来+ = 12345;
      结果=（无符号整数）（后/ 65536）％，2048;      下一个* = 1103515245;
      接下来+ = 12345;
      结果与所述;＆下; = 10;
      结果^ =（无符号整数）（后/ 65536）1024％;      下一个* = 1103515245;
      接下来+ = 12345;
      结果与所述;＆下; = 10;
      结果^ =（无符号整数）（后/ 65536）1024％;      *种子=下一个;      返回结果;
    }
 

解决方案

您可以把三个级别线程安全的，我将在这里进行编号以便于参考的。

1）不是线程安全的。这是不安全的，从多个线程同时调用该函数。例如， strtok的。

2）螺纹相对于该系统的安全。它是安全的，从多个线程同时调用的函数，只要不同的调用不同的数据进行操作。例如， rand_r ，的memcpy 。

3）螺纹相对于数据的安全。它是安全的，从多个线程同时调用功能，即使作用在相同的数据。例如的pthread_mutex_lock 。

rand_r 为2级，并在C（在POSIX规范尤其是）上下文中的约定是称之为线程安全的。

在其他一些语言，比如Java，习惯上是指3级为线程安全的以及其他一切为不是线程安全的。因此，例如 java.util.Vector中的是线程安全和的java.util.ArrayList 是不是线程安全的。当然，的java.util.ArrayList 处于2级所以从Java的未来自然会调用一个程序员 rand_r 和的memcpy 不是线程安全的。

在C中的惯例不同的是，也许是因为内部同步数据结构是相当罕见的开始。在C的环境下，你可能会问：是的文件句柄线程安全的吗？，而谈论3级，但问什么时候是这个函数是线程安全的？这通常意味着2级。

Well, rand_r function is supposed to be a thread safe function. However, by its implementation, I cannot believe it could make itself not change by other threads. Suppose that two threads will invoke rand_r in the same time with the same variable seed. So read-write race will occur. The code rand_r implemented by glibc is listed below. Anybody knows why rand_r is called thread safe?

 int
    rand_r (unsigned int *seed)
    {
      unsigned int next = *seed;
      int result;

      next *= 1103515245;
      next += 12345;
      result = (unsigned int) (next / 65536) % 2048;

      next *= 1103515245;
      next += 12345;
      result <<= 10;
      result ^= (unsigned int) (next / 65536) % 1024;

      next *= 1103515245;
      next += 12345;
      result <<= 10;
      result ^= (unsigned int) (next / 65536) % 1024;

      *seed = next;

      return result;
    }

解决方案

You can think of three levels of thread safety, which I'll number here for ease of reference.

1) Not thread safe at all. It is unsafe to call the function concurrently from multiple threads. For example, strtok.

2) Thread safe with respect to the system. It is safe to call the function concurrently from multiple threads, provided that the different calls operate on different data. For example, rand_r, memcpy.

3) Thread safe with respect to data. It is safe to call the function concurrently from multiple threads, even acting on the same data. For example pthread_mutex_lock.

rand_r is at level 2, and the convention in the context of C (in particular in the POSIX specification) is to call this "thread safe".

In some other languages, such as Java, the convention is to refer to level 3 as "thread safe" and everything else as "not thread safe". So for example java.util.Vector is "thread safe" and java.util.ArrayList is "not thread safe". Of course all the methods of java.util.ArrayList are at level 2. So a programmer coming from Java might naturally call rand_r and memcpy "not thread safe".

In C the convention is different, perhaps because internally synchronised data structures are fairly rare to begin with. In the context of C you might ask "are file handles thread-safe?", and be talking about level 3, but when asking "is this function thread-safe?" that generally means level 2.

这篇关于rand_r是否是真实的线程安全的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！