Is mutex locking necessary for a pointer variable?

Is mutex locking necessary for a section of code that includes a pointer (where the pointer points to data that is part of a critical section)? Code example:

struct list { int i; struct list *next; }; int modify_second_elem(struct list *head, int val); void * func1(void *ptr); void * func2(void *ptr); int modify_second_elem(struct list *head, int val) { if(head == NULL) return 1; /* Check to see if second element exists. Here, I am using indirection to get the next pointer. Would I need synchronization here? */ if(head->next == NULL) return -1; pthread_mutex_lock(&list_lock); (head->next)->i = val; pthread_mutex_unlock(&list_lock); return 0; } void * func1(void *ptr) { struct list *head; head = (struct list *) ptr; modify_second_elem(head, 4); } void * func2(void *ptr) { struct list *head; head = (struct list *) ptr; modify_second_elem(head, 6); } void main() { struct list *el1, *el2, *el3; pthread_t th1, th2; el1 = (struct list *) malloc(sizeof(list)); el2 = (struct list *) malloc(sizeof(list)); el3 = (struct list *) malloc(sizeof(list)); el1->i = 1; el1->next = el2; el2->i = 2; el2->next = el3; el3->i = 3; el3->next = NULL; pthread_create(&th1, NULL, &func1, (void *) el1); pthread_create(&th2, NULL, &func2, (void *) el1); pthread_join(th1, NULL); pthread_join(th2, NULL); exit(EXIT_SUCCESS); } 
+4
source share
4 answers

Not enough information to give a really good answer. How is s "published" to other threads? How do other topics subscribe to s ? In what data structure are struct s objects stored?

So, I will give a general answer:

For each type of data that is shared between streams, synchronization is required. This includes generic pointers.

About pointers:

You may have heard that on some regular CPUs, the load / stock of correctly aligned pointers is atomic (this does not apply to all CPUs or for all types of pointers, for example: distant pointers to an x86 non-atom). Stay away from using this if you do not have a complete understanding of your CPU / VM memory model, there are many subtle things that can go wrong if you do not take locks (locks provide fairly strong guarantees).

Edit:

In your example, neither th1 nor th2 changes the list, they only change the elements of the list. So, in this particular case, you do not need to block the list, you just need to block the list items (the pointer conceptually belongs to the implementation of the linked list).

In more typical cases, some threads will move around the list, while others will change the list (add and remove items). This requires locking the list or using some kind of algorithm without locking.

There are several ways to make this lock.

  • Have a global lock on the list and use it also for list items.
  • Use hierarchical locking , lock the list, and lock each item. To read / change an element, you first need to lock in the list, find the element, take the element lock, release the list lock, process the element, and finally release the element lock. This is useful if you need to perform complex element processing and do not want to prevent other threads from accessing the list. You must ensure that you always take locks in the same order to avoid deadlocks.
+4
source

Locks are used to protect a critical section in code. If your variable is in a critical section, you need to protect it with some kind of lock.

+4
source

Lock is used to protect critical partitions . This has nothing to do with a variable that is a pointer or not.

In your case, you do not need to block this check. Since s is a parameter that cannot be accessed from outside your function. However, the specified data is not local to your function, so you may need to block access to this data.

+2
source

It depends on what other operations you can have on s . For example, another value of the flow change s->c depending on what s->i :

 if (s->i == 1) { s->c = 'x'; } else { s->c = 'y'; } 

In this case, you cannot omit the mutex lock, otherwise you can set both s->i and 1, and s->c to 'y'.

+2
source

Source: https://habr.com/ru/post/1347443/


All Articles