newbie to multi threading
-
minkowski wrote:
what is this for? boost::mutex io_mutex; To say you wish to define a boost::mutex lock and call it io_mutex?
Yes
minkowski wrote:
In the for loop a scoped lock is used. Does that mean any object used within the scope of the for loop is locked?
No - it means that the thread containing the for loop will own the mutex within the for loop
minkowski wrote:
Does the lock only lock "this"? How do I lock other objects or do I have to use a scoped lock in the member function?
The lock isn't explicitly attached to the thing it locks - it's more of a conceptual relationship. What it means in this case is that only one thread at once can execute the line
std::cout << id << ": " << i << std::endl;.Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Hey thanks for that. So basically, anything that is in the for loop is only executable by 1 thread? If so, what if I have some member functions for a class, say a
get()and aset()and I only want one thread at a time to access either of them (preventing a read occuring the same time as a write). How would I lock them? -
Hey thanks for that. So basically, anything that is in the for loop is only executable by 1 thread? If so, what if I have some member functions for a class, say a
get()and aset()and I only want one thread at a time to access either of them (preventing a read occuring the same time as a write). How would I lock them?minkowski wrote:
So basically, anything that is in the for loop is only executable by 1 thread
Yup.
minkowski wrote:
If so, what if I have some member functions for a class, say a get() and a set() and I only want one thread at a time to access either of them
Same sort of thing - using the same threading classes as before:
class MyClass
{
void SetMyObject(SomeClass const& value)
{
boost::mutex::scoped_lock lock(objectMutex);
myObject = value;
}
SomeClass SetMyObject() const
{
boost::mutex::scoped_lock lock(objectMutex);
return myObject;
}
private:
SomeClass myObject;
boost::mutex objectMutex;
};Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
minkowski wrote:
So basically, anything that is in the for loop is only executable by 1 thread
Yup.
minkowski wrote:
If so, what if I have some member functions for a class, say a get() and a set() and I only want one thread at a time to access either of them
Same sort of thing - using the same threading classes as before:
class MyClass
{
void SetMyObject(SomeClass const& value)
{
boost::mutex::scoped_lock lock(objectMutex);
myObject = value;
}
SomeClass SetMyObject() const
{
boost::mutex::scoped_lock lock(objectMutex);
return myObject;
}
private:
SomeClass myObject;
boost::mutex objectMutex;
};Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
So from your example, say one thread accesses the
SetMyObject(), given that there is a lock in the function, it will also lock theGetMyObject()blocking any other thread from calling? This kind of implies that wherever in the object there is a lock, any function owned by the object will be locked to any other thread trying to access. Is this correct? Thanks again for your help. -
So from your example, say one thread accesses the
SetMyObject(), given that there is a lock in the function, it will also lock theGetMyObject()blocking any other thread from calling? This kind of implies that wherever in the object there is a lock, any function owned by the object will be locked to any other thread trying to access. Is this correct? Thanks again for your help.minkowski wrote:
So from your example, say one thread accesses the SetMyObject() , given that there is a lock in the function, it will also lock the GetMyObject() blocking any other thread from calling?
Yes
minkowski wrote:
This kind of implies that wherever in the object there is a lock, any function owned by the object will be locked to any other thread trying to access. Is this correct?
Sort of - any function that attempts to acquire (lock) the mutex will be serialized, as only one thread can acquire the mutex at a time. So, that means if you have a group of functions that acquire the lock, only one of that group can be executed concurrently. There are other sorts of locks that may better suit different situations (semaphores, read-write locks) - part of learning how to design multi-threaded systems is knowing which sort of synchronisation mechanism to use.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
minkowski wrote:
So from your example, say one thread accesses the SetMyObject() , given that there is a lock in the function, it will also lock the GetMyObject() blocking any other thread from calling?
Yes
minkowski wrote:
This kind of implies that wherever in the object there is a lock, any function owned by the object will be locked to any other thread trying to access. Is this correct?
Sort of - any function that attempts to acquire (lock) the mutex will be serialized, as only one thread can acquire the mutex at a time. So, that means if you have a group of functions that acquire the lock, only one of that group can be executed concurrently. There are other sorts of locks that may better suit different situations (semaphores, read-write locks) - part of learning how to design multi-threaded systems is knowing which sort of synchronisation mechanism to use.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Hey thanks for that, it tidied up some of my uncertainties. I was wondering how C++ knows to lock the other member function if one is being accessed by another thread. In the thread constructor itself you pass in either a function pointer or overloaded
operator()in your class. So for the case of an object, there must be some reference to thethispointer for the object for it to know to lock the other member functions if a lock is in place from another thread. Was wondering if this is correct? Thanks for any information. -
Hey thanks for that, it tidied up some of my uncertainties. I was wondering how C++ knows to lock the other member function if one is being accessed by another thread. In the thread constructor itself you pass in either a function pointer or overloaded
operator()in your class. So for the case of an object, there must be some reference to thethispointer for the object for it to know to lock the other member functions if a lock is in place from another thread. Was wondering if this is correct? Thanks for any information.minkowski wrote:
I was wondering how C++ knows to lock the other member function
It doesn't. The locking is contained within the mutex implementation. When you acquire a mutex, you either get retun immediately with ownership of the mutex, or your thread waits inside the OS until you do get ownership.
minkowski wrote:
Was wondering if this is correct?
As explained above, no :-) Can I suggest you read up on how mutexes[^] work[^]? That should maybe make things a bit clearer...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
minkowski wrote:
I was wondering how C++ knows to lock the other member function
It doesn't. The locking is contained within the mutex implementation. When you acquire a mutex, you either get retun immediately with ownership of the mutex, or your thread waits inside the OS until you do get ownership.
minkowski wrote:
Was wondering if this is correct?
As explained above, no :-) Can I suggest you read up on how mutexes[^] work[^]? That should maybe make things a bit clearer...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Oh I see, so since its the same lock object (
objectMutexfrom your example in theget()andset()functions) of course it will be locked?That's it. So, as each instance of MyClass has a separate instance of objectMutex, you can access different instances of MyClass concurrently on separate threads, but not the same instance (because the mutex will stop you).
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
That's it. So, as each instance of MyClass has a separate instance of objectMutex, you can access different instances of MyClass concurrently on separate threads, but not the same instance (because the mutex will stop you).
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
My pleasure
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p