General questions about mutexes and threading

[Shump]

Hi! I've got two questions about SFML's threads and mutexes.

First, a general question about sharing variables and objects between threads. Is it necessary to use mutexes to lock an object both when you're reading and writing to it or is it enough just locking it when you write to it. In other words, what happens if a thread is reading an object, that is not locked, and then another thread wants to lock and write to it? It seems much more efficient to just lock it only when you need to change it, otherwise, the program may end up spending more time locking and unlocking an object just to get read and write access to it.

My second question is about functions(and methods as well) and threads. What happens if a thread wants to use a function at the same time as another? Is it necessary and possible to use mutexes to lock and unlock access to functions aswell?

[Core Xii]

Is it necessary to use mutexes to lock an object both when you're reading and writing to it or is it enough just locking it when you write to it. In other words, what happens if a thread is reading an object, that is not locked, and then another thread wants to lock and write to it? It seems much more efficient to just lock it only when you need to change it, otherwise, the program may end up spending more time locking and unlocking an object just to get read and write access to it.

This is called a read-write lock. What you do is you have a variable that indicates if the resource is being read or written. You use a mutex for reading this variable. Each thread locks the mutex, reads that variable, and then decides what to do:

• If the thread wants to read, and the resource is flagged for reading, go ahead and read
  
• If the thread wants to read, and the resource is flagged for writing:
  • If there are threads waiting to write, wait
  • If there are no threads waiting to write, flag it for reading, wait for the current writing thread to finish, then go ahead and read
• If the thread wants to write, and the resource is flagged for reading, flag it for writing, wait for the current reading threads to finish, then go ahead and write
  
• If the thread wants to write, and the resource is flagged for writing, wait for the current writing thread to finish, then go ahead and write
  

Note that you actually need more than one variable for this condition. Let's see...

• Whether the resource is being written
• How many threads are reading it (each thread will increment/decrement this)
• How many threads are waiting to read
• How many threads are waiting to write

These are not exact instructions, more like guidelines.

[Shump]

Thanks a lot for your answer! However, it seems a bit paradoxical. Don't I get the same problem with the variables for how many threads there are waiting to read/write?

[Core Xii]

Essentially, yes. If the actual *work* your threads are doing is taking less time than the overhead of multi-threading, you shouldn't be multi-threading at all.

[Shump]

I'm afraid I have to, unless I have got it completely wrong, since I'm using it to handle my network and it's necessary too have at least two threads; one for listening and one for sending.

Anyway, I think I'll just go for the easy "lock-whenever-I-need-to-wrote-or-read", because the only data-sharing I'll probably need is when the server get a new input from client and is sending it along the the rest of the program, which may not be too often, or at least not constantly.