I understand that shared variables should be locked when multiple threads are reading or writing it at the same time to avoid concurrency issue. However, in a single writer multiple reader environment, I suspect the necessity for the writer thread to lock that variable when it is reading from it. My reasoning is that since it is the only writer, no other threads might modify the content, so it is impossible to get undefined behavior.

In other words, is read lock really necessary in my_read_1 ? What are the consequences if it is omitted?

/********* Thread A *********/
hlist_head_t g_my_table[MY_TABLE_SIZE];
pthread_rwlock_t g_my_lock;

void my_update(uint64_t hash, hlist_node_t *node)
{
    pthread_rwlock_wrlock(&g_my_lock);

    hlist_head_t *head = &g_my_table[hash % MY_TABLE_SIZE];
    hlist_add_head(node, head);

    pthread_rwlock_unlock(&g_my_lock);
}

void my_read_1(uint64_t hash)
{
    // TODO: is read lock necessary here?

    hlist_head_t *head = &g_my_table[hash % MY_TABLE_SIZE];
    if (hlist_empty(head)) {
        printf("empty\n");
    } else {
        printf("%p %p\n", head->first->next, head->first->pprev);
    }
}


/********* Thread B *********/
extern hlist_head_t g_my_table[MY_TABLE_SIZE];
extern pthread_rwlock_t g_my_lock;

void my_read_2(uint64_t hash)
{
    pthread_rwlock_rdlock(&g_my_lock);

    hlist_head_t *head = &g_my_table[hash % MY_TABLE_SIZE];
    if (hlist_empty(head)) {
        printf("empty\n");
    } else {
        printf("%p %p\n", head->first->next, head->first->pprev);
    }

    pthread_rwlock_unlock(&g_my_lock);
}

I understand that shared variables should be locked when multiple threads are reading or writing it at the same time to avoid concurrency issue. However, in a single writer multiple reader environment, I suspect the necessity for the writer thread to lock that variable when it is reading from it. My reasoning is that since it is the only writer, no other threads might modify the content, so it is impossible to get undefined behavior.

In other words, is read lock really necessary in my_read_1 ? What are the consequences if it is omitted?

/********* Thread A *********/
hlist_head_t g_my_table[MY_TABLE_SIZE];
pthread_rwlock_t g_my_lock;

void my_update(uint64_t hash, hlist_node_t *node)
{
    pthread_rwlock_wrlock(&g_my_lock);

    hlist_head_t *head = &g_my_table[hash % MY_TABLE_SIZE];
    hlist_add_head(node, head);

    pthread_rwlock_unlock(&g_my_lock);
}

void my_read_1(uint64_t hash)
{
    // TODO: is read lock necessary here?

    hlist_head_t *head = &g_my_table[hash % MY_TABLE_SIZE];
    if (hlist_empty(head)) {
        printf("empty\n");
    } else {
        printf("%p %p\n", head->first->next, head->first->pprev);
    }
}


/********* Thread B *********/
extern hlist_head_t g_my_table[MY_TABLE_SIZE];
extern pthread_rwlock_t g_my_lock;

void my_read_2(uint64_t hash)
{
    pthread_rwlock_rdlock(&g_my_lock);

    hlist_head_t *head = &g_my_table[hash % MY_TABLE_SIZE];
    if (hlist_empty(head)) {
        printf("empty\n");
    } else {
        printf("%p %p\n", head->first->next, head->first->pprev);
    }

    pthread_rwlock_unlock(&g_my_lock);
}

• c
• multithreading
• concurrency
• readwritelock

Share Improve this question Follow asked Mar 25 at 11:51 davidhcefxdavidhcefx 30533 silver badges1313 bronze badges 3

• 2 The read lock iss needed if write is not atomic. – 0___________ Commented Mar 25 at 12:07
• 1 @EricPostpischil, I've deleted my previous comment. You are right. I failed to notice that my_read_1 is declared under the heading, ***Thread A***. OTOH, if I were writing it, I would either have it lock the mutex anyway, or else I would declare it under a block comment that said, WARNING! my_read_1 must only be called be called by Thread A because... But, since I don't like to see comments in code if the need can be eliminated by changing the code itself, and since it's less typing, I almost certainly would just have it lock the mutex. – Solomon Slow Commented Mar 25 at 12:39
• 2 @0___________: Data races occur only between threads. Within a thread, a read will not see a partial write. (If the hardware requires multiple operations to update an object, the compiler is responsible for ensuring they are not visible within a thread. unsigned i = 255u; ++i; printf("0x%x\n", i); can only print 0x100, never 0x0 or 0x101.) – Eric Postpischil Commented Mar 25 at 13:43

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 2

In other words, is read lock really necessary in my_read_1 ? What are the consequences if it is omitted?

The requirement that must be satisfied is that every pair of accesses (reads or writes) to an object must be properly ordered if at least one of them is a write. The limitation of this requirement to the cases where at least one access is a write is what makes read / write locks sensible -- reads don't need to be synchronized with respect to each other, only with respect to writes.

Accesses by different threads are ordered via synchronization objects, such as locks. A read / write lock provides for ordering pairs of writes and pairs of one read and one write, without requiring or providing for ordering of pairs of reads. This can be advantageous.

But notwithstanding the general use of locking by a program, every pair of access by the same thread is ordered by the single-thread execution order of the program, so a thread does not need to use locking to order its own reads and writes with respect to each other. Therefore, if only one thread ever writes to the shared data then that thread does not need to use locking to protect its reads of that data.