Newbie question: new/delete

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

MechSoft - 12 Mar 2005 00:07 GMT

I have a question regarding deleting a dynamically created objects.

Thread 1 of my application create a new object using "new", say
MyClass* p1 = new MyClass
And I pass the address pointer to thread 2, where pointer p2 stores the
address from p1, thread 1. My question is: can I successfully delete the
object by
delete p2;
in thread 2?

Thanks a lot!!

Reply to this Message

Carl Daniel [VC++ MVP] - 12 Mar 2005 01:23 GMT

> I have a question regarding deleting a dynamically created objects.
>
[quoted text clipped - 5 lines]
> delete p2;
> in thread 2?

Yep.

-cd

Reply to this Message

William DePalo [MVP VC++] - 12 Mar 2005 01:28 GMT

>I have a question regarding deleting a dynamically created objects.
>
[quoted text clipped - 5 lines]
> delete p2;
> in thread 2?

Generally, yes, you can.

That's because the threads of your process always share the same virtual
address space so pointers have the "same meaning" across threads.

The threads also need to share the same C++ heap for dynamic memory
allocations for this to work. If both threads were created in the same
executable (either .dll file or .exe file) that's guaranteed.

Regards,
Will

Reply to this Message

Larry Brasfield - 12 Mar 2005 03:01 GMT

>>I have a question regarding deleting a dynamically created objects.
>>
[quoted text clipped - 7 lines]
>
> Generally, yes, you can.

I would have to qualify that assurance. If you are using
either the multi-threaded static form of the C runtime,
or its multi-threaded DLL form, then there should be
no problem with using the allocator from multiple threads.
However, if you link against the single-threaded static
form of the CRT, then it would be prudent to avoid
using the allocation routines, along with many others
that are designed for only single-threaded use.

> That's because the threads of your process always share the same virtual address space so pointers have the "same meaning" across
> threads.

I would agree with that statement provided no call
into the allocator is active.

Signature

--Larry Brasfield
email: donotspam_larry_brasfield@hotmail.com
Above views may belong only to me.

Reply to this Message

William DePalo [MVP VC++] - 12 Mar 2005 05:17 GMT

> I would have to qualify that assurance. If you are using
> either the multi-threaded static form of the C runtime,
[quoted text clipped - 4 lines]
> using the allocation routines, along with many others
> that are designed for only single-threaded use.

All very true. But realize the the recent tools don't even let you call
__beginthreadex() when building against the single threaded runtime. Yes, I
know, that still leaves Win32's CreateThread() to cause grief. OP, if you
are "listening", forget CreateThread() exists; using it is _almost_ always
the wrong thing to use in a C or C++ application.

It's always a fine line to walk providing advice here. There is rarely a
question that can be answered adequately in a line or two. Too much
information increases the chances that the OP won't understand. That's why I
used the qualifier, "generally" and tried to steer the OP away from try to
sharing runtime widgets across a DLL boundary.

>> That's because the threads of your process always share the same virtual
>> address space so pointers have the "same meaning" across threads.
> I would agree with that statement provided no call
> into the allocator is active.

I'm not sure I get you here. Do you mean that you have to prevent one thread
from deleting an object to which another holds a pointer? If so, I heartily
agree. But that's just one example of the kinds of things to consider in a
multi-threaded environment. No matter which runtime the OP uses, he has to
synchronize access to the "updates" of the objects he shares among threads
just as the runtime does. But the mere choice of proper runtime won't do
that for him.

Regards,
Will

Reply to this Message

Larry Brasfield - 12 Mar 2005 05:42 GMT

>> I would have to qualify that assurance. If you are using
>> either the multi-threaded static form of the C runtime,
[quoted text clipped - 8 lines]
> threaded runtime. Yes, I know, that still leaves Win32's CreateThread() to cause grief. OP, if you are "listening", forget
> CreateThread() exists; using it is _almost_ always the wrong thing to use in a C or C++ application.

My concern here is that it is easy to initiate threads with
CreateThread(), especially since the docs purporting to
describe _{begin,end}thread{,ex}() do not provide the
slightest clue as to *why* they should be called. As far
as those docs will say, those functions do little beyond
merely wrapping the CreateThread() API.

> It's always a fine line to walk providing advice here. There is rarely a question that can be answered adequately in a line or
> two. Too much information increases the chances that the OP won't understand. That's why I used the qualifier, "generally" and
> tried to steer the OP away from try to sharing runtime widgets across a DLL boundary.

I generally agree with your position relative to that line. <g>

>>> That's because the threads of your process always share the same virtual address space so pointers have the "same meaning"
>>> across threads.
[quoted text clipped - 5 lines]
> No matter which runtime the OP uses, he has to synchronize access to the "updates" of the objects he shares among threads just as
> the runtime does. But the mere choice of proper runtime won't do that for him.

That last statement of mine was quite unclear. Sorry.
What I was trying to say, (in too few words), is:
Use of the allocator in the single-threaded CRT should
be strictly serialized. Otherwise, no pointers to the kind
of objects being discussed, (see subject line), can be
assumed to have any useful meaning. Better yet, be sure
to never use the single-threaded CRT in a multi-threaded
program. This can be assured by using _beginthreadex()
to create threads.

Best regards,

Signature

--Larry Brasfield
email: donotspam_larry_brasfield@hotmail.com
Above views may belong only to me.

Reply to this Message

Newbie question: new/delete

Free Magazines