memory management within multiple threads

I’ve a little dumb question. Inside a multithreaded application all threads
must cooperate and all the memory inside the application is shared.
Are there some way to mprotect a segment of memory between threads so
ONLY some segments of memory are shared and/or detect when some threads
access these segments?

I probably already know the answer of this question. However I’m
setting up an application and I was deciding about splitting up the
application with multiple threads or multiple processes that shares
data. The multithreaded model fits better under my context and it’s
probably easier to set up.

This application doesn’t have a clare threaded model since each thread
could easily work indipendenty of each other sharing some structure for
communication. But I was thinking about the
implications of memory leaks and exceptions. A crash of a thread under
a multithreaded application would probably crash the whole application
but a crash of a separated program would probably stop the application
until the process come back. Of course I’ve my good reasons for thiking
that an application crash is worse than a little pause.

So what I could “do” about managing threads over communicating and
syncronizing? There’s some way to protect, limit the thread execution
space?

Bests


Wave++

“Wave++” <wavexx@ngweb.it> wrote in message news:abkajs$5hh$1@inn.qnx.com

I’ve a little dumb question. Inside a multithreaded application all
threads
must cooperate and all the memory inside the application is shared.
Are there some way to mprotect a segment of memory between threads so
ONLY some segments of memory are shared and/or detect when some threads
access these segments?

I probably already know the answer of this question. However I’m
setting up an application and I was deciding about splitting up the
application with multiple threads or multiple processes that shares
data. The multithreaded model fits better under my context and it’s
probably easier to set up.

This application doesn’t have a clare threaded model since each thread
could easily work indipendenty of each other sharing some structure for
communication. But I was thinking about the
implications of memory leaks and exceptions. A crash of a thread under
a multithreaded application would probably crash the whole application
but a crash of a separated program would probably stop the application
until the process come back. Of course I’ve my good reasons for thiking
that an application crash is worse than a little pause.

So what I could “do” about managing threads over communicating and
syncronizing? There’s some way to protect, limit the thread execution
space?

My educated guess is that you can’t, by defnition threads are sharing
memory.
For example if you were to mmap a block of memory with the MAP_PRIVATE
even though it won’t be availble to other process it will be available
to all threads. I beleive the memory mapping/layout granulatiry is
processes
not threads, otherwise that would imply that context switch between threads
of same process would take as long as context switch between process.

By definition context switch between threads imply a simpler (and faster)
context switch where page table doesn’t need to be changed. Hence threads
MUST be sharing the same memory maping.

This is NOT an official answer :wink:


Bests


Wave++

Mario Charest <goto@nothingness.com> wrote:

“Wave++” <> wavexx@ngweb.it> > wrote in message news:abkajs$5hh$> 1@inn.qnx.com> …
I’ve a little dumb question. Inside a multithreaded application all
threads
must cooperate and all the memory inside the application is shared.
Are there some way to mprotect a segment of memory between threads so
ONLY some segments of memory are shared and/or detect when some threads
access these segments?

I probably already know the answer of this question. However I’m
setting up an application and I was deciding about splitting up the
application with multiple threads or multiple processes that shares
data. The multithreaded model fits better under my context and it’s
probably easier to set up.

This application doesn’t have a clare threaded model since each thread
could easily work indipendenty of each other sharing some structure for
communication. But I was thinking about the
implications of memory leaks and exceptions. A crash of a thread under
a multithreaded application would probably crash the whole application
but a crash of a separated program would probably stop the application
until the process come back. Of course I’ve my good reasons for thiking
that an application crash is worse than a little pause.

So what I could “do” about managing threads over communicating and
syncronizing? There’s some way to protect, limit the thread execution
space?

My educated guess is that you can’t, by defnition threads are sharing
memory.
For example if you were to mmap a block of memory with the MAP_PRIVATE
even though it won’t be availble to other process it will be available
to all threads. I beleive the memory mapping/layout granulatiry is
processes
not threads, otherwise that would imply that context switch between threads
of same process would take as long as context switch between process.

By definition context switch between threads imply a simpler (and faster)
context switch where page table doesn’t need to be changed. Hence threads
MUST be sharing the same memory maping.

This is NOT an official answer > :wink:

You can make it official, Mario – everything in the address space of a
process is available to all threads (to be anal, even the so-called
“per thread storage area” is theoretically available to each and every
thread – it’s just inconvenient to access it :slight_smile:)

Cheers,
-RK


Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

Wave++ <wavexx@ngweb.it> wrote:

I’ve a little dumb question. Inside a multithreaded application all threads
must cooperate and all the memory inside the application is shared.
Are there some way to mprotect a segment of memory between threads so
ONLY some segments of memory are shared and/or detect when some threads
access these segments?

No, there is no way to protect memory between threads in the same
process.

You can use mutexes and stuff like that to avoid stomping on memory
while someone else is using it, but they are, essentially, advisory.

I probably already know the answer of this question. However I’m
setting up an application and I was deciding about splitting up the
application with multiple threads or multiple processes that shares
data. The multithreaded model fits better under my context and it’s
probably easier to set up.

Multi-threaded can be easier to setup – but the resiliency and ease
of debugging for the multi-process model is probably worth it.

This application doesn’t have a clare threaded model since each thread
could easily work indipendenty of each other sharing some structure for
communication. But I was thinking about the
implications of memory leaks and exceptions. A crash of a thread under
a multithreaded application would probably crash the whole application
but a crash of a separated program would probably stop the application
until the process come back. Of course I’ve my good reasons for thiking
that an application crash is worse than a little pause.

If you split things up into seperate processes, it is generally easier
to recover from a partial failure – and generally easier to track down
where the failure occurred and fix it.

So what I could “do” about managing threads over communicating and
syncronizing? There’s some way to protect, limit the thread execution
space?

There are all the posix synchronisation tools – mutexes, condvars,
reader/writer locks, etc. But, all are advisory – they allow you
to synchronise before accessing memory, but they provide no particular
protection.

In fact, even if you could protect memory between threads, the expected
behaviour on a failure would be a segmentation violation, which would
result in the failure of your large, do-everything process as well.

You can put mutexes, condvars, rwlocks, semaphores, etc in a shared
memory area between processes – so going multi-process does not lose
you the use of those tools. And, it gains you the segmented protection
that you are looking for – only the bits you explicitly want to share
will be shared, by putting them in a shared memory area.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

You could write some kind of cover function to access your shared memory.
The cover function could ‘enforce’ any protection you require.

“Wave++” <wavexx@ngweb.it> wrote in message news:abkajs$5hh$1@inn.qnx.com

I’ve a little dumb question. Inside a multithreaded application all
threads
must cooperate and all the memory inside the application is shared.
Are there some way to mprotect a segment of memory between threads so
ONLY some segments of memory are shared and/or detect when some threads
access these segments?

I probably already know the answer of this question. However I’m
setting up an application and I was deciding about splitting up the
application with multiple threads or multiple processes that shares
data. The multithreaded model fits better under my context and it’s
probably easier to set up.

This application doesn’t have a clare threaded model since each thread
could easily work indipendenty of each other sharing some structure for
communication. But I was thinking about the
implications of memory leaks and exceptions. A crash of a thread under
a multithreaded application would probably crash the whole application
but a crash of a separated program would probably stop the application
until the process come back. Of course I’ve my good reasons for thiking
that an application crash is worse than a little pause.

So what I could “do” about managing threads over communicating and
syncronizing? There’s some way to protect, limit the thread execution
space?

Bests


Wave++