Solved

thread

Posted on 2011-03-11
8
508 Views
Last Modified: 2012-08-13
In one thread I am doing:

1) Thread 1 does the following:
The list has 4 objects to start with
               std::list<myObj*>::iterator myIterator = myObj.begin();
                std::list<myObj*>::iterator myIterator_end =myObj.end();
                for (; myIterator != myIterator_end ; myIterator ++) {
                    (*myIterator )->callSomething();
                }

->callSomething() is waiting on object 1 as it is waiting to acquire lock


2. Thread 2 removed object 2 from the above list.
3. Thread 1 gets the lock on  callSomething() for object 1.
4. Inside the for loop, will thread 2 try to call callSomething() for object 2 (which was already deleted in step 2) or will it directly go to execute callSomething() for object 3
0
Comment
Question by:learningunix
8 Comments
 

Author Comment

by:learningunix
ID: 35112434
Inside the for loop, should I check if the object really exists before calling callSomething()

How do I check if an object exists or is not null?

0
 
LVL 1

Expert Comment

by:mbkirk
ID: 35112657
Maybe I'm being dense (no surprise) but I'm not entirely sure i understand what's locked where.  

Both thread 1 and thread 2 have to use the same locks for the objects - only one thread should be using a list at a time.
here's your code with line numbers

1                std::list<myObj*>::iterator myIterator = myObj.begin();
2                std::list<myObj*>::iterator myIterator_end =myObj.end();
3               for (; myIterator != myIterator_end ; myIterator ++) {
4                    (*myIterator )->callSomething();
5                }

If you lock before line 1 and unlock after line 5, and in thread 2 use the same locking object to create a mutex zone around your list element removal, then you should be ok.
If you never reference the list in either thread 1 or thread 2 without the lock then you should be ok.  If on the other hand you don't always lock the list then you're engaging in risky behavior.
0
 
LVL 1

Expert Comment

by:mbkirk
ID: 35112701
on your second question if you've handled the list and members correctly then you'll only ever get back objects that are valid, assuming they were valid when you put them in the list.

That said you can use NULL...

e.g.

void x (char* y)
{
if (y != NULL) printf("%s\n", y);
else printf ("not anything useful\n");
}
0
Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 

Author Comment

by:learningunix
ID: 35112736
Ideally one thread should be using. I agree but in my case i am using different lock on the same list as one is active (thread 2) and the thread 1 above is passive with function callSomething()

0
 

Author Comment

by:learningunix
ID: 35112759
or I can do

try catch and ignore the exception.
0
 
LVL 11

Accepted Solution

by:
DeepuAbrahamK earned 500 total points
ID: 35114342
Ideally your thread pool should be using one common lock and it should check the number of items in the list appropriately since it keep changing dynamically.
0
 
LVL 53

Expert Comment

by:Infinity08
ID: 35115028
>> 2. Thread 2 removed object 2 from the above list.

I'll assume you are using the erase function for that

In that case, for a std::list, it is guaranteed that all iterators (or references, or pointers) into that std::list will still be valid after the erase operation. Except, of course, for those iterators (or references, or pointers) that refer to the erased item.

So :

>> 4. Inside the for loop, will thread 2 try to call callSomething() for object 2 (which was already deleted in step 2)

As long as you perform proper locking, and (as has been mentioned above by mbkirk) NEVER let more than one thread manipulate the list at the same time, erasing an item in one thread will not impact iterators in other threads (as long as they don't refer to the erased item).
0
 

Author Closing Comment

by:learningunix
ID: 35130698
correct, i was using different lock on list
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article shows you how to optimize memory allocations in C++ using placement new. Applicable especially to usecases dealing with creation of large number of objects. A brief on problem: Lets take example problem for simplicity: - I have a G…
Go is an acronym of golang, is a programming language developed Google in 2007. Go is a new language that is mostly in the C family, with significant input from Pascal/Modula/Oberon family. Hence Go arisen as low-level language with fast compilation…
The goal of this video is to provide viewers with basic examples to understand how to use strings and some functions related to them in the C programming language.
The goal of the tutorial is to teach the user how to use functions in C++. The video will cover how to define functions, how to call functions and how to create functions prototypes. Microsoft Visual C++ 2010 Express will be used as a text editor an…

856 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question