Web Images Groups Books Scholar Blogs Gmail more »
Recently Visited Groups | Help | Sign in
Google Groups Home
deletion of objects problem - multi-threaded program
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  7 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Angus  
View profile  
 More options Nov 7, 2:00 am
Newsgroups: comp.lang.c++
From: Angus <anguscom...@gmail.com>
Date: Fri, 6 Nov 2009 06:30:50 -0800 (PST)
Local: Sat, Nov 7 2009 2:00 am
Subject: deletion of objects problem - multi-threaded program
Hi

I have written a program which runs two threads.  One thread controls
the creation and modification of an object used in the program.
Another thread periodically checks a list of these objects and deletes
an object from the list if no longer required.

I have written a class to wrap the operating system specific lock /
unlock of the object.  This works fine.  But I get the following
problem:

1. thread 1 creates object1.

2. thread 2 checks object1 to see if ready for deletion and it
eroneously considers it is.

3. thread 1 modifies object1.

4. (simultaneously with 3.) deletes object1.

Result is an access violation as at 3. a pointer to object1 is
dereferenced.

My possible solutions for this problem are:

1. Add a lock and unlock function to the object1 class.  Then have to
lock, perform manipulation, then unlock.  But then if a instruction
was waiting for the access control/critical section to free up and the
object gets deleted - then what happens?

2. Don't actually delete object1.  Simply mark it as deletable.  then
have another thread check when possible to delete object1 say every
hour - when there is no chance that thread1 would be doing anything
with object1.

Noe of these solutions seems ideal.  Or maybe I am not understanding
correctly.

Does anyone have any suggestions?

Angus


    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Victor Bazarov  
View profile  
 More options Nov 7, 3:25 am
Newsgroups: comp.lang.c++
From: Victor Bazarov <v.Abaza...@comAcast.net>
Date: Fri, 06 Nov 2009 10:55:01 -0500
Local: Sat, Nov 7 2009 3:25 am
Subject: Re: deletion of objects problem - multi-threaded program

Angus wrote:
> I have written a program which runs two threads.  One thread controls
> the creation and modification of an object used in the program.
> Another thread periodically checks a list of these objects and deletes
> an object from the list if no longer required.

What indicates that the object is "no longer required"?

> I have written a class to wrap the operating system specific lock /
> unlock of the object.  This works fine.  But I get the following
> problem:

> 1. thread 1 creates object1.

> 2. thread 2 checks object1 to see if ready for deletion and it
> eroneously considers it is.

So, if you know that it's erroneous, why don't you simply correct the
error?  What is the criterion thread 2 uses to "see if ready for
deletion"?  If it's a flag, let thread 1 set it upon creation of the
object.  IOW, the indicator has to be set by thread 1 and checked in
thread 2.

> 3. thread 1 modifies object1.

> 4. (simultaneously with 3.) deletes object1.

> Result is an access violation as at 3. a pointer to object1 is
> dereferenced.

> My possible solutions for this problem are:

> 1. Add a lock and unlock function to the object1 class.  Then have to
> lock, perform manipulation, then unlock.  But then if a instruction
> was waiting for the access control/critical section to free up and the
> object gets deleted - then what happens?

Huh?

> 2. Don't actually delete object1.  Simply mark it as deletable.  then
> have another thread check when possible to delete object1 say every
> hour - when there is no chance that thread1 would be doing anything
> with object1.

There is no need for the third thread.  Define what it is that indicates
that the object is deletable, then only set that indicator in thread 1
and only check that indicator (and actually delete the object) in thread
2.  Before that indicator is set, the object is alive.  Setting of the
indicator and checking it should be atomic.

> [..]

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Marcel Müller  
View profile  
 More options Nov 7, 11:15 pm
Newsgroups: comp.lang.c++
From: Marcel Müller <news.5.ma...@spamgourmet.com>
Date: Sat, 07 Nov 2009 12:45:15 +0100
Local: Sat, Nov 7 2009 11:15 pm
Subject: Re: deletion of objects problem - multi-threaded program
Hi,

Angus wrote:
> 1. thread 1 creates object1.

> 2. thread 2 checks object1 to see if ready for deletion and it
> eroneously considers it is.

why? Thread 2 must not do this mistake.

> 3. thread 1 modifies object1.

> 4. (simultaneously with 3.) deletes object1.

> Result is an access violation as at 3. a pointer to object1 is
> dereferenced.

Obviously.

> My possible solutions for this problem are:

> 1. Add a lock and unlock function to the object1 class.  Then have to
> lock, perform manipulation, then unlock.  But then if a instruction
> was waiting for the access control/critical section to free up and the
> object gets deleted - then what happens?

A lock won't solve your problem. (It might solve other concurrency issues.)

> 2. Don't actually delete object1.  Simply mark it as deletable.  then
> have another thread check when possible to delete object1 say every
> hour - when there is no chance that thread1 would be doing anything
> with object1.

The expression 'no chance' has no meaning for concurrency issues. So
don't rely on that. Although think what happens if all objects that your
application uses reside in memory for at least one hour. Depending on
you application this might be a serious problem.

> Noe of these solutions seems ideal.

True. You need thread 1 to tell when it does no longer need the object.
The easiest solution is to use reference counting. And the strongly
recommended way to do so is to use smart pointers. Have a look at
boost::shared_ptr or boost::intrusive_ptr. Once you use them
consequently you might not need thread 2 at all, because it is straight
forward when the object is no longer needed. This is exactly when no
(smart) pointer to the object exists. In this case you cannot access the
object anymore because you don't know where it lies in memory.
The smart pointer will automatically delete your object if the last
reference has gone. For this to work, you must not hold any ordinary
pointers or references to object. Exception: if you are absolutely sure
that a longer lived smart pointer instance points to the same object the
whole time.

Marcel


    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Maxim Yegorushkin  
View profile  
 More options Nov 8, 12:42 am
Newsgroups: comp.lang.c++
From: Maxim Yegorushkin <maxim.yegorush...@gmail.com>
Date: Sat, 07 Nov 2009 13:12:17 +0000
Local: Sun, Nov 8 2009 12:42 am
Subject: Re: deletion of objects problem - multi-threaded program
On 07/11/09 11:45, Marcel Müller wrote:

Agree, reference counting solve this issue easily.

I once worked on a mature multithreaded system where people did not
heard about smart-pointers or reference counting. They had exactly the
same problem when threads shared objects and could not destroy them
orderly. They came up with a reaper thread whose sole purpose was to
destroy objects. And it worked about 99% of the time, since with no
reference counters race conditions were still present that would crash
the application or make it use corrupted objects.

--
Max


    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Brian Wood  
View profile  
 More options Nov 8, 2:16 pm
Newsgroups: comp.lang.c++
From: Brian Wood <woodbria...@gmail.com>
Date: Sat, 7 Nov 2009 18:46:29 -0800 (PST)
Local: Sun, Nov 8 2009 2:16 pm
Subject: Re: deletion of objects problem - multi-threaded program
On Nov 6, 9:55 am, Victor Bazarov <v.Abaza...@comAcast.net> wrote:

> There is no need for the third thread.  Define what it is that indicates
> that the object is deletable, then only set that indicator in thread 1
> and only check that indicator (and actually delete the object) in thread
> 2.  Before that indicator is set, the object is alive.  Setting of the
> indicator and checking it should be atomic.

This is probably clear to some, but I will add a note on that
last sentence.  I think he's saying that setting of the
indicator should be atomic.  Likewise checking the indicator
should be atomic.

Brian Wood
http://www.webEbenezer.net


    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Chris M. Thomasson  
View profile  
 More options Nov 8, 4:00 am
Newsgroups: comp.lang.c++
From: "Chris M. Thomasson" <n...@spam.invalid>
Date: Sat, 7 Nov 2009 08:30:19 -0800
Local: Sun, Nov 8 2009 4:00 am
Subject: Re: deletion of objects problem - multi-threaded program
"Angus" <anguscom...@gmail.com> wrote in message

news:f86819de-b1ef-4946-a5a1-e08432f3e81b@j24g2000yqa.googlegroups.com...

Hopefully it will seg-fault ASAP and not corrupt anything!

;^o

> 2. Don't actually delete object1.  Simply mark it as deletable.  then
> have another thread check when possible to delete object1 say every
> hour - when there is no chance that thread1 would be doing anything
> with object1.

Why not have the thread which "marks it" actually delete it? What's this
other thread going to do anyway? What type of "post-processing" do
"to-be-deleted" objects require?

> Noe of these solutions seems ideal.  Or maybe I am not understanding
> correctly.

> Does anyone have any suggestions?

I need more information. However, for now, why not have Thread 1 put object
than can be deleted into a queue which is consumed by Thread 2? Thread 2
just waits on that queue and any objects which come through are quiescent
wrt Thread 1? When you mark an object as "deletable", is said object truly
in a persistent quiescent state??? This is important...

    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Chris M. Thomasson  
View profile  
 More options Nov 8, 4:53 am
Newsgroups: comp.lang.c++
From: "Chris M. Thomasson" <n...@spam.invalid>
Date: Sat, 7 Nov 2009 09:23:07 -0800
Local: Sun, Nov 8 2009 4:53 am
Subject: Re: deletion of objects problem - multi-threaded program
"Maxim Yegorushkin" <maxim.yegorush...@gmail.com> wrote in message

news:4af57231$0$9752$6e1ede2f@read.cnntp.org...
[...]

> I once worked on a mature multithreaded system where people did not heard
> about smart-pointers or reference counting. They had exactly the same
> problem when threads shared objects and could not destroy them orderly.
> They came up with a reaper thread whose sole purpose was to destroy
> objects. And it worked about 99% of the time, since with no reference
> counters race conditions were still present that would crash the
> application or make it use corrupted objects.

FWIW, IMHO traditional reference counting can be "overkill" for many
problems. Sometimes you just know when a part of you're application is in a
quiescent state.

;^)


    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2009 Google