• Advertisement
Sign in to follow this  

Multithreading wrappers?

This topic is 4147 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello! Lets say I have a collection class and want to create a wrapper class that is safe for multithreading. Do I have to lock the collection for everything I do with it? For example:

class MyCollection
{
  int mCount = 10;
  
  virtual int count() { return mCount; }
  
  virtual void add(int value) { /**/ }
  virtual int getValue(int index) { /**/ }
}

class MySynchronizedCollection
{
  MyCollection mMyColl;
  object mSyncRoot; // == mMyColl

  /* ... */

  override int count() { 
    int count = 0;
    lock(mSyncRoot) {
      count = mMyColl.count();
    }
    return count;
  }
  
  virtual void add(int value) { /**/ }
  virtual int getValue(int index) { /**/ }
}


So, do I really have to put the locking mechanism in the count() for the synchronized version? Or do I only need to put this for functions that are more complex and change/use the internals of MyCollection? I mean, so what if another thread modifies the mCount variable, it's not like anything really bad will happen? Thanks!

Share this post


Link to post
Share on other sites
Advertisement
Exactly how many threads and how often will they be reading?

You can start with the simplest design -- lock during any access.

A cute variation is:

class ActualObject;

class LockingWrapperObject {
AutoLockingPointer<ActualObject> GetActual();
};


where you get a lock on the object by getting a smart pointer to the object.

...

Going a bit deeper, you can analyze the methods and determine if they are atomic. Atomic read-only methods can be safely left unlocked -- usually.

You often want to be able to lock an object, and do multiple operations in a row, guaranteed not to be interrupted by someone else. Having an EXTERNALLY accessable RAII based locking mechanism is useful for this.

...

Going a bit deeper, a reader/writer lock is a good plan if you have lots of concurrancy going on. Multiple readers at once, but only one writer, and you aren't allowed any readers if you have a writer.

Note there are dangers if you upgrade a Reader lock to a Writer lock. It can cause deadlocks. (you can add in the concept of a "Special Reader" who has the right to upgrade to a Writer. The Special Reader can exist at the same time as other Readers, but only one "Special Reader" or "Writer" can exist at one time. Such a "Special Reader" can be upgraded to a Writer without danger).

...

Going a bit deeper, you could become batshit crazy and think "I want to create a lock-free thread-safe collection structure". If you get that crazy, feel free. I wouldn't advise it -- first learn how to write lock based collection stuctures. :)

Note that lock-free, wait-free and obstruction-free multithreaded algorithms/data structures are currently a topic of active research, and they are not easy to implement.

Edit: added some clarifications.

[Edited by - NotAYakk on October 15, 2006 11:18:31 AM]

Share this post


Link to post
Share on other sites
Wow, thank you very much NotAYakk! Seems like I really didn't know much about multithreading :/ Got some reading to do ;)

rating up up
C ya

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement