0

Although this question has been asked in different ways in SO, i will ask it from pthreads perspective in a different way to know the tools to provide synchronization.

We know that each thread has it's own thread stack, but shares the heap and global data. When the heap is shared, i am confused how and which synchronization tool to provide to protect the full heap?

RajSanpui
  • 11,556
  • 32
  • 79
  • 146
  • 1
    Are you asking if [`malloc` is thread-safe?](http://stackoverflow.com/questions/855763/malloc-thread-safe) – Carl Norum Jun 25 '13 at 17:48
  • This is too general a question for stackoverflow. You're basically asking how synchronization primitives work in pthreads, which is far too large to answer as a single "question". Check documentation on the pthread_mutex_* and pthread_cond_* functions in whatever tutorial Google gives you, then come back with the specific questions you have. – Andy Ross Jun 25 '13 at 17:50
  • @CarlNorum: Another way to view the same problem. IS malloc performed inside individual thread functions safe? And after malloc individual threads tampering with the same heap address, that is another case. – RajSanpui Jun 25 '13 at 17:50
  • @AndyRoss: lol..This question is not about sync primitives, it's centered only around heap. Sync primitives are easy to apply in case of mmaped segments, shared memory or even global data using pthread_mutex_lock or even semaphores. That is pretty straightforward unlike this case what i have asked. – RajSanpui Jun 25 '13 at 17:52
  • 1
    `malloc` is thread safe as far as its metadata is concerned. Synchronizing access to the allocated data itself is up to you. – n. m. could be an AI Jun 25 '13 at 17:52
  • I'm not sure how I see how a global variable is different from a heap-allocated block of memory as far as synchronization is concerned. – Carl Norum Jun 25 '13 at 17:53
  • `malloc` is *not* thread safe unless your documentation says it is. newlib, for example, requires you to implement `__malloc_lock()` and `__malloc_unlock()`. – Carl Norum Jun 25 '13 at 17:53
  • @CarlNorum If your implementation provides pthreads and no thread-safe malloc, time to look for a less brain-dead implementation. – n. m. could be an AI Jun 25 '13 at 17:57
  • I'll agree with that. – Carl Norum Jun 25 '13 at 18:00
  • 2
    @CarlNorum: More specifically, [POSIX threads specification require `malloc` and most everything else to be thread-safe](http://pubs.opengroup.org/onlinepubs/7908799/xsh/threads.html) (*all* non-thread-safe interfaces are listed on that page). – n. m. could be an AI Jun 25 '13 at 18:09
  • @kingsmasher1: in what ways protecting a chunk of heap-allocated data is less straightforward than protecting a chunk of static data? Can you show a code example that illustrates the difference? – n. m. could be an AI Jun 25 '13 at 18:18
  • @n.m.: No there is not. I take back my words :-) Have you seen an `electric fence` http://linux.die.net/man/3/efence? What it does is an mmaped memory set to PROT_NONE after a limit so that whenever there is a wrong interference it throws a SEGfault, and prohibits to access that part. I think you got my hint. Sorry if i sound too confusing, but couldn't find any other way to explain. – RajSanpui Jun 25 '13 at 18:30
  • 1
    I know about efence but fail to see how it relates. – n. m. could be an AI Jun 25 '13 at 18:35
  • @n.m.:Similar way, i wish there was some way, so that when one thread accesses the heap, the other if it tries to access the same location should receive a fault or something similar? In case of efence this was possible because it was a mapped memory, but can't see any way to achieve it in case of heap memory – RajSanpui Jun 25 '13 at 18:40
  • You synchronize access to data by handing participants a locked mutex and politely asking them to wait. It doesn't mater what kind of data it is. Do you have a problem with making sure that all participants access *same* data? – n. m. could be an AI Jun 25 '13 at 19:05

1 Answers1

1

There are two possibilities - either the functions your system provides to deal with the heap (malloc, free, etc.) are thread-safe or they're not.

If they are, no problem - you don't have to do anything.

If they're not, you'll need to write a wrapper function for each one that you want to use and lock appropriately. pthread_mutex_* calls seem appropriate to me.

Carl Norum
  • 219,201
  • 40
  • 422
  • 469
  • What baffles my mind is, assume before calling to `pthread_create` we allocate memory in heap. `ptr = malloc(xx)` then do, `ptr_thread1 = ptr` and `ptr_thread2 = ptr`, and both threads take each pointer. Now, `pthread_mutex_lock` if i use, they can lock same segments of code that is shared. But how to make sure that the actual pointer location that each of the threads that points to is actually protected, which is the heap segments. – RajSanpui Jun 25 '13 at 18:00
  • Make `ptr` global and don't bother with `ptr_thread1` or `ptr_thread2`. Lock access to `ptr` too, if you want. – Carl Norum Jun 25 '13 at 18:01
  • So you mean, some kind of conditional lock, that when one is using ptr, the other should not etc. ISn't there a better way to protect the heap, rather than the access to variable? – RajSanpui Jun 25 '13 at 18:04
  • 1
    kingsmasher1: once again you seem to be asking about generic synchronization techniques and not e.g. the threadsafety of malloc(). – Andy Ross Jun 25 '13 at 18:07
  • @AndyRoss: Is there any difference between heap safety and general synchronization primitives? I think you missed my above comment where i stated: ` Apart from thread safety of malloc individual threads tampering with the same heap address` is my concern. – RajSanpui Jun 25 '13 at 18:15
  • No, there is no difference. – Carl Norum Jun 25 '13 at 18:17