mfc >> Are collection methods like GetSize thread safe?

by Richard Hollis » Mon, 31 Jan 2005 05:55:12 GMT

Can you go ahead and call GetSize/GetCount without having to use a CS around
the call, if all you want is the size and you don't intend to then iterate
the collection or use the size in anyway, apart from the metric.

Is there anywhere in MSDN that thread safety of MFC calls is documented?
There isn't anything at the method level.

Thanks
Richard




mfc >> Are collection methods like GetSize thread safe?

by Scott McPhillips [MVP] » Mon, 31 Jan 2005 06:30:47 GMT





In all cases, MFC objects are not thread safe. You must provide your
own multithreading synchronization.

--
Scott McPhillips [VC++ MVP]




mfc >> Are collection methods like GetSize thread safe?

by Richard Hollis » Mon, 31 Jan 2005 06:45:39 GMT

Even if GetSize returns just an integer? What about just reading the
m_nSize integer?




around
iterate




Are collection methods like GetSize thread safe?

by Scott McPhillips [MVP] » Mon, 31 Jan 2005 10:16:06 GMT




Calling GetSize() is no different that reading the integer.

What if a list size is being changed (in another thread) when you read
the size? The size integer might not even be meaningful in such a case.
What if the size is stored at an unaligned address (requiring more
than one memory fetch)? What if there are two or more processors
accessing the integer, which may or may not be in the cache of one
processor? Etc. etc. It all depends, and because it all depends, your
code is responsible for synchronization.

The hell of it is that most of these "simple" interthread acceses will
work most of the time without synchronization, leading to the worst kind
of bug: "It only crashes once in a while." When dealing with data
shared between multiple threads you must tread very cautiously, and wear
a belt and suspenders, and hold on tight to your trousers.

--
Scott McPhillips [VC++ MVP]



Are collection methods like GetSize thread safe?

by Doug Harrison [MVP] » Mon, 31 Jan 2005 14:20:53 GMT





The variable should be properly aligned, and AFAIK, it's no bigger than a
DWORD, so there should be no word tearing. As long as you realize m_nSize
may not reflect the size of the collection at the moment you read it, and
that it may change immediately after you read it, you should be "OK",
provided you define "OK" as obtaining a value from an object that is in an
indeterminate state.

In addition, unsynchronized access is not a practice that will serve you
well much beyond the x86 architecture. Other platforms such as Sparc and
Itanium require the use of memory barriers to enforce memory visibility and
ordering between threads executing on different CPUs in MP systems. The
volatile keyword helps with this only if the compiler vendor makes it help,
and to date, few if any compiler vendors burden volatile in this way. If you
use proper synchronization techniques, e.g. mutexes or the InterlockedXXX
functions, you don't need volatile to achieve thread safety.

--
Doug Harrison
Microsoft MVP - Visual C++


Are collection methods like GetSize thread safe?

by Richard Hollis » Mon, 31 Jan 2005 15:36:58 GMT

Ok, that's great. Thank you both for helping to clear the fog on that one
for me.

[reaches for suspenders and belt]

Richard




Similar Threads

1. General thread question - Thread safe object properties & methods?

2. Implementing thread safe Queue collection object

Hi,

I've been reading the online documentation for the System.Collections.Queue 
object on how to implement a threadsafe Queue object. 

I understand the basics, by using the wrapper returned by Synchronised 
method, but I'm not sure how to implement it between 2 threads. Has anyone 
got any suggestions or examples?

Thanks
Macca

3. Thread-safe enumeration thru collection? - CSharp/C#

4. Problem with making collection classes thread-safe

Sander Verhagen wrote:
> If (in an extreme case) thread 2 clears my collection, between
> GetStartPosition and GetNext calls of thread 1... thread 1 will be
> 'screwed', won't it?
> 
> The only way I see to prevent this really is to have these threads call
> lock/unlock methods. But I was just trying to keep all the locking private
> and thus transparent. :-(
> Any smart solutions?

Use enumeration, user calls your EnumItems function and provides it's 
own EnumItemsProc function. Synchronization is handled in EnumItems.

5. Thread-safe initialization of a mutex, was Thread-safe initialization of a function static

6. Making a base class' methods thread safe

I am creating several data access objects that all derive from a base class 
which implements the web service access functionality.

For example (fake code):
<code>
public class DAOBase
{
    protected List<TType> Search<TType>(string nameHint)
    {
        //  code to login to web service session, execute search
        //  and return the result.
        return new List<TType>();
    }
}

public class CustomerDAO : DAOBase
{
    public List<Customer> GetCustomer(string name)
    {
        return base.Search<Customer>(name);
    }
}

public class OrderDAO : DAOBase
{
    public List<Order> GetCustomerOrders(string name)
    {
        //  some code that will execute a search using the DAOBase
        //  Search method
        return null;
    }
}
</code>

The web service access exposed in DAOBase is session based and I can only 
have one session at a time.  In other words, I can't run two searches at the 
same time, they must be synchronous.
Once I've logged in (expensive operation) I want to reuse the same session 
for all subsequent requests.

I'm thinking of the different ways that I can accomplish this.  One idea is 
to refactor my code so that my web service functionality is in a new 
Singleton class, then the base class would have an instance of this 
singleton.  This way I could keep my session alive in the singleton and all 
concrete objects would access the singleton through the base class.

This would give me thread safety, or, more accurately it won't prevent two 
web service requests from being invoked on top of each other.  If this 
happens, the session will be killed. (bad)

I need to implement a queue to handle the web service request(s) from the 
various concrete DAO classes, most likely using the command pattern and 
wrapping all request in an object that can be enqueued.

So that is my first and only real idea to solve the issue.  Another idea 
that is fluttering around in my head is to keep the web service access in 
the base class but make the methods static.  This will give me the single 
session shared with all concrete objects but introduces thread safety issues 
(I think).

I would really like to hear what any of you think, before I start modifying 
(and breaking) my code all over the place I thought I would ask first to see 
if I'm on the right track.

Thanks for any input,
Steve




7. Thread-safe methods... - CSharp/C#

8. can an instance method be thread safe

If an instance method does not alter the containing class or any arguments of 
a referenced type is it thread safe?

public void GetSomething() {
     return new Something(this.Name);
}
public string Name;

Thanks,

Mike