Home > Net >  Make struct object thread safe
Make struct object thread safe

Time:08-31

I have a function call

void moveMeToThread(UnsafeStruct *ptr)
{
// do stuff with ptr
}

Now I want to move moveMeToThread to a different thread, so I do not want anyone creating an object of UnsafeStruct on the stack and I also want memory of all UnsafeStruct objects made on the heap to be freed automatically. Anyone have an elegant way to do this?

CodePudding user response:

Sounds like you'd like to make a heap-only class. There are many ways to force this:

  • you might make private ctors (all of them!) and create a static create() function that returns a pointer (sometimes called named ctor)
  • you might make dtor private

The latter technically does not save you from placement new to a suitable memory block, but otherwise protects from sensible coding mistakes and is way more compatible with algorithms and containers. E.g. you can still copy such an object via copy ctor outside the class, which is not possible if you make all ctors private (which is a requirement for the first version).

You might do this:

template<typename T>
class HeapOnly
{
public:
    T t;
    operator       T&()       { return t; }
    operator const T&() const { return t; }
private:
    ~HeapOnly();
};

void moveMeToThread(HeapOnly<UnsafeStruct> *ptr)
{ /* ... */ }

int main()
{
    HeapOnly<UnsafeStruct> *ptr =
        new HeapOnly<UnsafeStruct>{/* args to UnsafeStruct */};

    moveToThread(ptr);
}

Small note: there's no such thing as (call/parameter) stack in the C standard. It only appears in ItaniumABI (and potentially in other ABIs). Standard says ASDV (automatic storage duration variables) for what's commonly referred to as 'on the stack', but nothing prevents an implementation to allocate the memory on the stack (as long as compiler can prove that the object's lifetime cannot extend the stack unroll - this works e.g. if it's allocated before static initialization). It might be completely unimportant in your case, but in security-related codes, where buffer overflow is important, you can't strictly enforce not having objects allocated from the same stack this way (and thus it's suggested to do a runtime check) - but you can still enforce that the object is allocated via new (or the given static member function).

CodePudding user response:

I do not want anyone creating an object of UnsafeStruct on the stack.

I want to forbid it because if someone creates an object on the stack and sends it on the thread, it can cause a crash(dangling pointer)

Do you also want to prevent anybody from creating int variables on the stack? Because if somebody creates an int variable on the stack, and if they allow a reference or a pointer to it to outlive the stack frame that contains the variable, then their program could crash.

Seriously.

That problem is older than C . That problem has existed since the very first edition of the C programming language. Every C and C programmer has to learn not to do that. Always have. Always will.


In some languages (e.g., Java, Python), No object of any kind can be allocated anywhere else except the garbage-collected heap. Variables can only hold references to objects, and dangling references are impossible. Programmers in those languages expect an assignment a=b to copy an object reference. That is, after the assignment, a and b both refer to the same object.

That's not the C way. C programmers expect that if some type T is publicly constructable, then they expect to be allowed to declare one wherever they want. And when they see a=b, they think of that assignment operator as copying a value. They expect that after the assignment, a and b still are two different objects that both have (in some sense) the same "value."

You will find more people saying positive things about your library if you design it to work in that same way.

  • Related