Sign in to follow this  
pcxmac

different threads cant delete eachother's variables ?

Recommended Posts

I have a couple threads running, and I believe if i "new" a variable from one thread, I cant delete that variable in another. Am I correct? context :: Thread 1 ... variable* newVar = new variable; .... context :: Thread 2 ... delete newVar; My program is crumping pretty hard and I think this is the issue. Even screwing up the OS too :) [Edited by - pcxmac on April 16, 2006 9:38:25 AM]

Share this post


Link to post
Share on other sites
It is not the deletion by itslef, it is ensuring that thread a isn't acessing the variable during or after the delete when thread b deletes it.

You will need to enure that the deletion ( and I assume you set the variable to 0/NULL to indicate it is gone ) and zeroing have to happen uninterrupted by other threads trying to access the variable.

What kind of mutexing are you doing?

Quote:

Even screwing up the OS too :)


And what the hell kind of Os are you running [grin]

Share this post


Link to post
Share on other sites
the first thread wont ever have to access that variable once its declared (client), its being declared in to a que, from which Thread two eventually gets around to handeling. I am not using any handles. But Im pretty sure there is a better way of doing it.

I am just asking if one thread creates a variable, is it protected from another thread deleting it? Ie. causing a program crash in the event there of.

before I started using the hard delete command, I was just stripping the variable off the que and not deleting it, leaving it in memory ( boo hoo ), and everything worked fine, no declaration collision issues as far getting in to the que and then the que being accessed. However thinking about it now, that in its self could be disasterous.

Share this post


Link to post
Share on other sites
What about the volatile keyword? (Definition here)
Would that be able to make it where a thread's variable(s) could be accessed by another?

(I don't know, and I really want to)

Share this post


Link to post
Share on other sites
Interesting.

Volatile Variables
(ISO C, §6.7.3) When you declare a volatile variable, the CodeWarrior C compiler takes the following precautions to respect the value of the variable:

The compiler stores commonly used variables in processor registers to produce faster object code. However, the compiler never stores the value of a volatile variable in a processor register.
The compiler uses its common sub-expression optimization to compute the addresses of commonly used variables and the results of often-used expressions once at the beginning of a function to produce faster object code. However, every time an expression uses a volatile variable, the compiler computes both the address of the volatile variable and the results of the expression that uses it.
Listing 3.1 shows an example of volatile variables.

Listing 3.1 Volatile Variables
void main(void)
{
int i[100];
volatile int a, b; /* a and b are not cached in registers. */

a = 5;
b = 20;

i[a + b] = 15; /* compiler calculates a + b */
i[a + b] = 30; /* compiler recalculates a + b */
}
The compiler does not place the value of a, b, or a+b in registers. But it does recalculate a+b in both assignment statements.

Share this post


Link to post
Share on other sites
Quote:
Original post by pcxmac
the first thread wont ever have to access that variable once its declared (client), its being declared in to a que, from which Thread two eventually gets around to handeling. I am not using any handles. But Im pretty sure there is a better way of doing it.

I am just asking if one thread creates a variable, is it protected from another thread deleting it? Ie. causing a program crash in the event there of.


I made a quick test program here to see what happens. 2 threads, each sharing a variable. it is initially zero. Thread a, when seeing the varaible as zero, immediatly uses new on it. Otherwise it dereferences it. Thread b, whenseeing the variable as non-zero, derefences it and then may delete & zero it.

This is done without any synchronisation. I just wanted to see how long before the crash [grin].

It works for a while, until said crash.

What kind of objects are you passing? Is the deconstructor referencing other shared memory? Can we see some code?

Share this post


Link to post
Share on other sites
Quote:
Original post by deadimp
What about the volatile keyword? (Definition here)
Would that be able to make it where a thread's variable(s) could be accessed by another?

(I don't know, and I really want to)


No, volatile only tells the compiler not to assume that it is the only thing that changes the value of this variable. So it will "reload" the value on subsequent references.

It cannot "make" the compiler share the variable( definition of threads involves such sharing anyway ), as the c/c++ standard doesn't deal with multithreading

Share this post


Link to post
Share on other sites
most of the classes in my program inherit from a base class called terminal, that is the mechanism in which most are linked, using a linked list structure (LIFO stack).

I link an object (derived from class "node") to a "compile" que, in which is owned by another thread.

In the other Thread's "main" procedure, one of its tasks is to pop each node out of the que and "render" it, by "compiling" the higher level (inheritance) object (GL_COMPILE).

So it renders the object, and the first thread (client) that originally linked the "request" (node), never uses the object again, except, ... (doh) ... I will eventually, but for now no.

At any rate the client will eventually want to access any derivative of that object, so I have something to consider. (Im trying to build a program based on a-synchronous networking, and I havent considered different threads and synchronization, except in my "thread class" as it relates to proper initialization, before execution)


-- its not being accessed by another thread, as my link requests are the last to be processed by my main thread, I have two other threads (input) and (graphics), its not an access problem, unless the main thread, in the background, w/out my coding trys to check up on the (inserted - to - que) node

Also the code crashes before the system quits, there by me knowing that its not the main thread's call to delete that node(where it was created w/out new), that clashes, with an already "deleted" node.


"
Thread Local Storage
All threads of a process share its virtual address space. The local variables of a function are unique to each thread that runs the function. However, the static and global variables are shared by all threads in the process. With thread local storage (TLS), you can provide unique data for each thread that the process can access using a global index. One thread allocates the index, which can be used by the other threads to retrieve the unique data associated with the index.
"

Im gonna look in to my code, I know both threads can read the variable, ...

When I debugged it

inside this function :

"e" in main is the variable being poped in node::pop (toBeDeleted)


void node::pop()
{
stub* toBeDeleted = last;
last = last -> last;
last->next = (stub*)this;
delete (stub*)toBeDeleted;
};


00416285: 8320FB and dword ptr [eax],0xfffffffb



void GLBuild::compile()
{
while (last != (stub*)this)
{
offset = (GLIobject*)last->socket;
offset->compile(NULL);
pop();
};
};

main()
{ ...
stub a,b,c,d,e,f; // link class, holds linked list chain info

myGR.build.link(&textureMap,&e); // texture map is derived fromnode

...
};







It crashes right after or during the delete procedure, the other threads arnt even near it (the variable in question). Maybe its my compiler?

still crashes.

[Edited by - pcxmac on April 16, 2006 10:54:26 AM]

Share this post


Link to post
Share on other sites
Can we see the relevant destructors?

If its crashing during deletion, then thats probably the problem. Also, try making a test rig where you do the exact smae thing, except without the threading, to see if the threading is affecting it.

Share this post


Link to post
Share on other sites
the destructor for the link class is empty, nothing is in it.
Node has a virtual destructor but its not being called, cause I can trace the path in my debugger. Its weird, I need to think about my "queing another thread" procedure / concept. Sorry if I frustrated anyone, both threads could read from the variable, I suspect that the cause is that one thread cant delete an allocated variable created by another. (It could just be metrowerks though)

I just created the same class in the main thread as was created in another thread, when I deleted the main thread (in the main thread) class it deleted with out troubles, however, when I tried to delete the other thread's instantiated class, it crumped.



DXDevice* myDevice = (DXDevice*)mindy.last->last->socket; // derived from class which is threaded - aka mindy

DXDevice* thisDevice = new DXDevice; // same kind of class

delete (DXDevice*)thisDevice; // works with out hitch
delete (DXDevice*)myDevice; // crumps after completing 99% of destructor, locks up in assembly.




Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this