обертка для добавления безопасности потока стиля omp copyin к произвольным данным (включая членов класса)

0

#pragma omp parallel for copyin(blah) отлично, если вам нужна другая копия blah для каждого потока, но имеет некоторые недостатки

  1. он не работает, если blah является переменной-членом класса
  2. blah может быть полиморфным, и только некоторым подклассам может понадобиться семантика copyin

Имея дело с ситуацией №2, я придумал следующее решение, которое, похоже, работает, но я хотел бы знать, хорошая ли это идея.

using namespace boost;
class OMPCopyInWrapper
{
    vector<shared_ptr<WrappedObject> > wrappedobjects;
    mutex m;
    WrappedObject& get_wrapped_object()
    {
        lock_guard<mutex> lock(m);
        assert(wrappedobjects.size() > 0);
        // create new objects by copying first one if needed
        while (omp_get_thread_num() >= wrappedobjects.size())
            wrappedobjects.push_back(shared_ptr<WrappedObject>(
                new WrappedObject(*wrappedobjects[0])
                ));
        return *(wrappedobjects[omp_get_thread_num()]);
    }

public:
    OMPCopyInWrapper(Blah blah)
    {
        wrappedobjects.push_back(shared_ptr<WrappedObject>(
            new WrappedObject(blah)));
    }
    forwarded_method(Foo foo)
    {
        return get_wrapped_object().method(foo);
    }
};

(Как показано выше, это специфично для WrappedObject но общедоступные методы могут, предположительно, быть обобщенными, например, в стиле scoped_ptr).

Может ли кто-нибудь выявить проблемы с этим?

Теги:
multithreading
thread-safety
openmp
mutex

1 ответ

0

Поскольку никто не ответил через пять дней, и с тех пор я нашел серьезную проблему с вышеуказанным кодом, я отправлю его здесь. Он правильно обрабатывает потоки OMP в процессе (я думаю), но может потерпеть неудачу, если несколько процессов называют, например, одну и ту же разделяемую библиотеку. Это должно быть нормально, если каждый вызов библиотеки создает собственный OMPCopyInWrapper.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню