Thread Memory Model

[P@u1]

Hi everyone,

I want to use sfml's threads to create a chat programm.
I want to use threads for that, because I don't think that it is reasonable possible to make a good chat while avoiding the use of additional threads (please tell me if this is wrong). I also want to use network for games later and probably there threads are essential too (again please tell me if this is wrong).

I know thread from java.
At java you always must ensure that changes to data which you apply become visible to other threads by either using the volatile keyword or with locks.
So I was wondering, what memory modell the SFML threads use...
In the tutorial this is not really mentioned.
I am not talking about using locks for example to make compound changes, im just talking about plain values like some integers.
Operations on integers are probably atomic, but thats not what i'm talking about.
At java you must ensure that a write to an integer is made visible to other threads, how is that with SFML?
Does sfml have sequential consistency (afaik this means that all changes immediately become visible to other thread) as memory model ?
Atleast this is implied by the tutorial in which an boolean is changed without any means of synchronisation.

Please give me some information. It would not be nice to use threads without knowing, which dangers it does or does not have.

[Laurent]

I don't know what Java does, but in C++, threads all share the memory space of their parent process. So any variable which is modified by a thread is automatically "updated" in other threads, because they all access it at the same memory address.

[P@u1]

Im not sure what exactly is the problem because of which you do need this in java.
But I think atleast a part of the problem is the cpu cache.
So writes might only go to cache and might not be visible for other cpu cores.
And when you read a variable it can also be read from cpu cache, which might not be up to date.

Maybe there are also other problems.

Java inserts memory barriers if you use volatile or locks to prevent these problems.

[Laurent]

You can also use the volatile keyword in C++ to avoid the cache problem.

[mercurio7891]

The volatile keyword in C++ doesn't really solve all problems related to multithreading. You will end up marking everything volatile which probably slow your code more instead.

I suggest using a memory barrier or fence instead.

Are you using gcc or msvc?

if you are using gcc then from gcc 4.6 and above there is the <atomic> header which when writing or reading you can specify a release or acquire schematic. This works just like a release/acquire lock. IIRC when you do a acquire mode read/write, no instructions after that read/write can be reorder above it, however instructions before the read/write can be reorder below it.
The release mode works the opposite. It prevents compiler from reordering instruction after the call.

Think of it as acquire lock, do work, release lock.

msvc has all the interlock functions which can serve as a full memory barrier or a release/acquire barrier which is similar to <atomic>

btw <atomic> is a C++0x std header.

regards

Good Only...........................

Multitasking is a process by which multiple tasks (also known as processes), share common processing resources such as a CPU.
class Thread
{
   public:
      Thread();
      int Start(void * arg);
   protected:
      int Run(void * arg);
      static void * EntryPoint(void*);
      virtual void Setup();
      virtual void Execute(void*);
      void * Arg() const {return Arg_;}
      void Arg(void* a){Arg_ = a;}
   private:
      THREADID ThreadId_;
      void * Arg_;

};

Thread::Thread() {}

int Thread::Start(void * arg)
{
   Arg(arg); // store user data
   int code = thread_create(Thread::EntryPoint, this, & ThreadId_);
   return code;
}

int Thread::Run(void * arg)
{
   Setup();
   Execute( arg );
}

/*static */
void * Thread::EntryPoint(void * pthis)
{
   Thread * pt = (Thread*)pthis;
   pthis->Run( Arg() );
}

virtual void Thread::Setup()
{
        // Do any setup here
}

virtual void Thread::Execute(void* arg)
{
        // Your code goes here
}


Cegonsoft
_________________________
Cegonsoft foundation