Re: C++ and odd pthread behavior
Re: C++ and odd pthread behavior
- Subject: Re: C++ and odd pthread behavior
- From: Kaveh Kardan <email@hidden>
- Date: Fri, 17 Mar 2006 18:50:56 -1000
Yes, my problem was due to a similar issue. Moving the call out of
the base class into each leaf class solved the problem.
Regards,
Kaveh
Kaveh Kardan Chief Technologist
email@hidden Academy for Creative Media
(808)956-5302 University of Hawaii
On Mar 15, 2006, at 12:49 AM, Steve Baxter wrote:
On 15 Mar 2006, at 06:25, Lawrence Gold wrote:
Kaveh Kardan wrote:
I'm encountering some very odd behavior when running multi-
threaded code
in XCode.
I have 4 threads which allocate tasks, push them onto a stack,
and pop
them off to execute them. The odd thing is that C++ on occasion
thinks
that the type of an object is actually that of its parent class, and
calls the parent's method instead of the object's. If I set the
number
of threads to 1, this does not happen and the code runs correctly.
The code also runs correctly with 4 threads on a Linux system.
Has anyone seen anything like this?
We saw something similar when we switched to preemptive threads a
while
back. In our base thread class's constructor, we call
pthread_create(),
which installs the start routine. The start routine in turn
invokes some
virtual methods. Sometimes, the virtual method for the base class was
being called rather than the derived class.
This was happening because the start routine would begin running
before
the object was fully constructed. The solution was to add a short
delay
via nano_sleep() to the beginning of the start routine (an
arbitrary 10ms).
It's definitely a hack, but I haven't been able to come up with
anything
more elegant. Probably the safest way to do it would be to install
the
start routine in a separate step:
DerivedThreadObject *obj = new DerivedThreadObject(...);
obj->StartRunning();
I have no idea if this describes the problem you're having, but I
hope
it can help someone. :-)
P.S. I just realized I might be able to achieve the same result by
overriding the new operator in the base thread class.
This is definitely a problem. Our solution was similar - we leave
it to the subclass to actually start the thread (so the subclass
can be sure that all instantiation has happened). I wouldn't use
nanosleep() - what if your machine was very busy paging? Nanosleep
might actually not sleep for long enough... nasty, nasty bug to
track down if it happens on a customer's system in Nebraska or
wherever).
Cheers,
Steve.
Stephen Baxter
Software Development Manager
Improvision
email@hidden
+44-2476-692229
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden