HBufC:s are basically just pointers to memory, and memory is shared between threads in the same process, so as long as your threads are in the same process, then yes.
Though, you must of course take all the normal thread concurrency safeguards, since there is no built in thread protection in them.
No problem though if you just create it in one thread, and then use it in another. Or if both threads just read from it after creation.
The problems comes when you are trying to access the HBufC simultaneously from both threads, and modifying the content from one of them.
You should also take a look at Message Queues, see if those fit what you need, those are a lot safer and easier to work with for more complex use-cases.
Well sharing memory between threads can mostly be done without hassle unless the thread was created to have it's own heap memory. It's quite easy to do so with an RThread::Create overload.
If the thread has its own heap or not doesn't really matter for shareing memory?
Regardless if the thread has its own heap or not, both threads share the same virtual memory space.
Shareing heap with the main thread, I would only recommend for simple threads, with easy error handling....
There are some issues involved with cleaning up allocated memory in the shared heap if the child thread unexpectedly die... (panic, not leave)
I belive you are correct. I mistakenly thought that when creating a separate heap for a new thread that it's memory would be protected from access by other threads.
I tend to use a shared heap with all my threads because it makes memory management a bit easier.
"the child thread unexpectedly die"
On the other hand, I agree that if your child thread has no communication with the parent thread it may be better to use a seperate heap (so that the memory is freed if the thread panics). Personally though I never use child threads that don't have some form of communication with the parent. Parent threads shouldn't really disown their children, at the very least they should "logon"...
If the thread has it own heap then it is not possible to access the objects present in another threads heap, even if both threads are in same address space.
If the thread tries to access any memory from another heap there will be KERN-EXEC 3 panic for access violation.
Concerning modification of HBufC, it is possible provided the treads share the same heap of process (they should not have their own heap). Pass the pointer as parameter while thread creation and later, inside the thread it can be used.
If the thread has it own heap then it is not possible to access the objects present in another threads heap, even if both threads are in same address space.
If the thread tries to access any memory from another heap there will be KERN-EXEC 3 panic for access violation.
No. You wont.
If you get Kern-Exec:s when trying to share objects between threads, it is not because of memory violation, but other reasons.
(One classic is Kern-Exec 0 because handles can't be shared between threads unless specifically created to be shareable)
The process is the unit of memory mapping, the OS will not remap your virtual memory when switching between threads.
(Thats part of the definition of the difference between a thread and a process)
I'm not just saying here, I have production code running that uses that exact fact.
On the other hand, I agree that if your child thread has no communication with the parent thread it may be better to use a seperate heap (so that the memory is freed if the thread panics). Personally though I never use child threads that don't have some form of communication with the parent. Parent threads shouldn't really disown their children, at the very least they should "logon"...
The problem is that "logon" in itself doesn't solve all problems.
You also need some way to get the pointers to all allocated cells allocated by that thread, and manually go through them and call "delete" on all of them.
Could possibly be done with smart usage of the cleanupstack, or some other way to pass a base pointer to the tree of all allocated cells by that thread to the main thread so it can clean it up, but most people seem to forget this.
The normal cleanup wont happen "automagically" when the thread panics.
If you let the thread has its own heap, that whole chunk containing the heap will be freed when the thread dies, so no need to clean it up manually, so the problem solves itself...
Sorry guys but I think that you started loosing point of my question. So I will ask again, giving you more info:
In first thread I create HBufC object. In second thread I want to write some data into it but when I call Des() method on it I always get panic User 42. I've take a look on this panic description and it says that this panic is raised by RHeap class. It checks if memory cell on which we want to work on belongs to current thread heap or not. So is there any way to around this limitation ?
class CWhatever : public CBase
{
public:
HBufC* iSharedBuf;
};
Thread 1:
iSharedBuf = HBufC::NewL(100);
Thread2:
iSharedBuf->Des() = someOtherBuf;
This should be fine if you have used the version of RThread::Create() that creates a thread using the same heap as the parent (you just pass NULL for the heap ptr IIRC)
"especially raghav_an"
Except that raghav doesn't know what he's talking about whereas alh does. The only major issue with having seperate heaps is that it is sometimes easy to "forget" which thread created an object so you end up calling delete on an object that is on a different thread's heap, which not surprisingly usually ends up generating some kind of panic.
And according to my SDK User 42 has nothing to do with threads!
And according to my SDK User 42 has nothing to do with threads!
I didn't write that that it has something with threads, I wrote
... when I call Des() method on it I always get panic User 42. I've take a look on this panic description and it says that this panic is raised by RHeap class. It checks if memory cell on which we want to work on belongs to current thread heap or not.
Forum posts: 1134
HBufC:s are basically just pointers to memory, and memory is shared between threads in the same process, so as long as your threads are in the same process, then yes.
Though, you must of course take all the normal thread concurrency safeguards, since there is no built in thread protection in them.
No problem though if you just create it in one thread, and then use it in another. Or if both threads just read from it after creation.
The problems comes when you are trying to access the HBufC simultaneously from both threads, and modifying the content from one of them.
You should also take a look at Message Queues, see if those fit what you need, those are a lot safer and easier to work with for more complex use-cases.
Forum posts: 4
Well sharing memory between threads can mostly be done without hassle unless the thread was created to have it's own heap memory. It's quite easy to do so with an RThread::Create overload.
Forum posts: 1134
If the thread has its own heap or not doesn't really matter for shareing memory?
Regardless if the thread has its own heap or not, both threads share the same virtual memory space.
Shareing heap with the main thread, I would only recommend for simple threads, with easy error handling....
There are some issues involved with cleaning up allocated memory in the shared heap if the child thread unexpectedly die... (panic, not leave)
Forum posts: 4
I belive you are correct. I mistakenly thought that when creating a separate heap for a new thread that it's memory would be protected from access by other threads.
Forum posts: 110
I tend to use a shared heap with all my threads because it makes memory management a bit easier.
"the child thread unexpectedly die"
On the other hand, I agree that if your child thread has no communication with the parent thread it may be better to use a seperate heap (so that the memory is freed if the thread panics). Personally though I never use child threads that don't have some form of communication with the parent. Parent threads shouldn't really disown their children, at the very least they should "logon"...
Forum posts: 95
Hi,
If the thread has it own heap then it is not possible to access the objects present in another threads heap, even if both threads are in same address space.
If the thread tries to access any memory from another heap there will be KERN-EXEC 3 panic for access violation.
Concerning modification of HBufC, it is possible provided the treads share the same heap of process (they should not have their own heap). Pass the pointer as parameter while thread creation and later, inside the thread it can be used.
Chao,
Raghav
Forum posts: 4
Then my original assumption was correct, good to know for future threading adventures
Forum posts: 49
Not good, but anyway thx guys
Forum posts: 1134
No. You wont.
If you get Kern-Exec:s when trying to share objects between threads, it is not because of memory violation, but other reasons.
(One classic is Kern-Exec 0 because handles can't be shared between threads unless specifically created to be shareable)
The process is the unit of memory mapping, the OS will not remap your virtual memory when switching between threads.
(Thats part of the definition of the difference between a thread and a process)
I'm not just saying here, I have production code running that uses that exact fact.
Forum posts: 1134
Raghav_an is also wrong about passing the HBufC into another thread and that it should be safe to modify it in that thread.
Its just not true...
And it doesn't matter if the heap is shared or not.
Only way its safe to modify memory in thread 1, at the same time that you are going to use in thread 0, is if you protect access to it with a Mutex.
Forum posts: 1134
The problem is that "logon" in itself doesn't solve all problems.
You also need some way to get the pointers to all allocated cells allocated by that thread, and manually go through them and call "delete" on all of them.
Could possibly be done with smart usage of the cleanupstack, or some other way to pass a base pointer to the tree of all allocated cells by that thread to the main thread so it can clean it up, but most people seem to forget this.
The normal cleanup wont happen "automagically" when the thread panics.
If you let the thread has its own heap, that whole chunk containing the heap will be freed when the thread dies, so no need to clean it up manually, so the problem solves itself...
Forum posts: 49
Sorry guys but I think that you started loosing point of my question. So I will ask again, giving you more info:
In first thread I create HBufC object. In second thread I want to write some data into it but when I call Des() method on it I always get panic User 42. I've take a look on this panic description and it says that this panic is raised by RHeap class. It checks if memory cell on which we want to work on belongs to current thread heap or not. So is there any way to around this limitation ?
Forum posts: 110
class CWhatever : public CBase
{
public:
HBufC* iSharedBuf;
};
Thread 1:
iSharedBuf = HBufC::NewL(100);
Thread2:
iSharedBuf->Des() = someOtherBuf;
This should be fine if you have used the version of RThread::Create() that creates a thread using the same heap as the parent (you just pass NULL for the heap ptr IIRC)
"especially raghav_an"
Except that raghav doesn't know what he's talking about whereas alh does. The only major issue with having seperate heaps is that it is sometimes easy to "forget" which thread created an object so you end up calling delete on an object that is on a different thread's heap, which not surprisingly usually ends up generating some kind of panic.
And according to my SDK User 42 has nothing to do with threads!
Forum posts: 110
Actually what am i talking about!? Your code should be fine regardless as you've only got one object on one heap!
Forum posts: 49
I didn't write that that it has something with threads, I wrote