[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 537
  • Last Modified:

thread

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
learningunix
Asked:
learningunix
1 Solution
 
learningunixAuthor Commented:
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
 
mbkirkCommented:
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
 
mbkirkCommented:
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
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.

 
learningunixAuthor Commented:
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
 
learningunixAuthor Commented:
or I can do

try catch and ignore the exception.
0
 
Deepu AbrahamR & D Engineering ManagerCommented:
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
 
Infinity08Commented:
>> 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
 
learningunixAuthor Commented:
correct, i was using different lock on list
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now