[2 days left] What’s wrong with your cloud strategy? Learn why multicloud solutions matter with Nimble Storage.Register Now

x
?
Solved

thread

Posted on 2011-03-11
8
Medium Priority
?
535 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
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
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 

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:
Deepu Abraham earned 2000 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

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

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

An Outlet in Cocoa is a persistent reference to a GUI control; it connects a property (a variable) to a control.  For example, it is common to create an Outlet for the text field GUI control and change the text that appears in this field via that Ou…
Basic understanding on "OO- Object Orientation" is needed for designing a logical solution to solve a problem. Basic OOAD is a prerequisite for a coder to ensure that they follow the basic design of OO. This would help developers to understand the b…
Video by: Grant
The goal of this video is to provide viewers with basic examples to understand and use while-loops in the C programming language.
The goal of this video is to provide viewers with basic examples to understand opening and reading files in the C programming language.

649 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