use defed class + atomicity

[highwayman]

Ok, so say I have a class and I want it to be thread safe. From what I can tell through my minimal knowledge, I can either surround the operations done on the objects of the class with a mutex, or I can use the atomic class. Now I get the general gist(hah that rhymed) of atomic with the loading and the storing or whatever, but I was thinking; a class is supposed to be practically homogeneous or however you want to say it, so a lot of the manipulation of the data in the object will be indirectly through a function. It seems like a strange thing to go obj.store(obj.load().fnc());, though, so is it better to make a class, and then surround it with the regular atomic template class, or is it better to make the individual data pieces atomic?

[kbw]

I think you've misunderstood atomics. They are the primitives that support "lock free" code, which isn't lock free at all, it just taps into the synchronisation that the hardware uses.

From what you're doing, it sounds like you need conventional synchronising mechanisms; semaphores, mutexes ....

[highwayman]

> I think you've misunderstood atomics.
not surprising lol. That I kinda knew, but I thought it was more like there are certain primitives that are already atomic, and then we created a mechanism in the atomic template class that emulated that atomicity. Why would they have a template class and all those atomic_t types? Seems strange to me.. all of this is purely a made up situation, just something I was thinking about earlier and was slightly confused as to what I would do, so I don’t really have code, sorry in advance if you wanted it.

[highwayman]

Semaphores look really awesome though, I’ve never heard of them (which is strange, but whatever) tried to do that with atomic_flag, but it just felt like so much work. The examples they give make it look a lot easier.

[dhayden]

I can either surround the operations done on the objects of the class with a mutex

You may need to think about what degree of thread safety you want to provide. To me, the class should ensure that two threads accessing different objects of your class are thread safe. So if your class objects access common data then the class needs to protect it. But if two threads access the same instance of your class, it's generally up to them, not the class, to serialize the access.

[highwayman]

Ok.. I think I get it now, yes ok yeah so like if I had a complex class and I’m working with just i in the two functions, then I make i an atomic integer instead of a regular integer?

[dhayden]

Let's suppose you have a complex class like this:

class Complex {
    double re, im;  // real and imaginary parts
    // Lots of methods and operators
};

And suppose you have two threads:
Thread 1:

Complex a,b,c;
// Do lots of stuff with a,b,c 

Thread 2:

Complex x,y,z;
// Do lots of stuff with x,y,z 

Then you probably don't need any locking in your Complex class. The two threads are dealing with separate instances of Complex and, presumably, when dealing with different instances of Complex, there's no common data that you need to worry about. In fact, the code should be designed that way.

Further, if the two threads deal with the same instance of complex, then it's up to the threads to guard against simultaneous access, not the class. Look at it this way, if the threads accessed the same int variable, you wouldn't expect int to lock itself to prevent simultaneous access.

I hope this helps.

[highwayman]

Mostly I think I get it now, though I might have started overthinking things now, but they are slightly unrelated. Thank you! :)