вопрос к профи

сам я думаю объявить в ГУИ-потоке, и доступ к ним осуществлять через указатель на главную форму

Лучше вынеси в отдельный класс, и указатель на инстанс отдай в каждый поток.

и доступ к ним осуществлять через указатель на главную форму

Дельфи головного мозга.

подскажите грамотное решение для таких случаев, стоит ли разделить приложение на процессы?

Нет.

плюс синхронизация через мьютексы или семафоры.

мьютексы

интенсивно ИСПОЛЬЗУЮТ и ИЗМЕНЯЮТ

может даже RW Lock, если несколько параллельных читателей

я же этот класс(или указатель на него, если динамически) помещу в public секции класса гуи-формы. получается доступ все равно будет через указатель на гуи-форму, тогда для чего переносить в отдельный класс? для читабельности?

ну так же понятнее :)

я же этот класс(или указатель на него, если динамически) помещу в public секции класса гуи-формы

У тебя появляется глобальная переменная - экземпляр формы. Глобальные переменные (и static-члены класса как вариант глобальной переменной) это источник 50% всех багов и проблем. Если есть возможность - а у тебя ЕСТЬ возможность, от них надо избавляться, поэтому создай контекст приложения и передавай этот контекст в конструкторы обработчиков нитей, основной формы и т.п.

class AppContext {
    string var1;
    int var2;
}

class MyForm extends Form {
    AppContext ctx;
    public MyForm(AppContext ctx) { super(); context = ctx; }
    public void DoSomething() {
       context.someMethod1();
    }
}

clas MyThreaded extends Runnable {
    AppContext context;
    public MyThreaded(AppContext ctx) { context = ctx; }
    public void Run() {
       context.someMethod2();
    }
}

int main() {
    AppContext ctx = new AppContext();
    (new MyForm(ctx)).show();
    (new Thread(new MyRunnable(ctx))).start();
    (new Thread(new MyRunnable(ctx))).start();
}

Эта методика позволяет отделить логику тредов от формы, превратить приложение в неинтерактивное с околонулевыми затратами, превратить приложение в многоэкземплярное - МНОГО ОДИНАКОВЫХ ФОРМ, ВНЕЗАПНО!!! Например, если твое приложение работает с базой данных, оно в твоей версии будет работать всегда только с одной базой, а в моей - в со сколь угодно большим количеством баз. А нити могут работать вообще без формы. У тебя такого не получится

Ты не первый кто пытается изобрести велосипед с треугольными колесами - может стоит взять круглые колеса, и поступить как тебе советуют более опытные люди?

используй mvc или хотя бы observer pattern.

А не лучше ли будет создать статический объект и брать указатель на инстанс? Если не трудно, прошу объяснить как лучше (чисто для себя).

А не лучше ли будет создать статический объект

Это то же самое, что «глобальная переменная объектного типа». Единственное существенно отличие глобальной переменной от static-атрибута - второй проще найти.

class A {
    public static A instance;
    public void doSomething() {}
}
...
A.instance.doSomething();

и чем это отличается от

global A global_a;
...
global_a.doSomething();

Согласен, сам дурак. Спасибо.

профи
Qt

Создавай в куче и используй read-write locks. Технически из какого потока не важно, но обычно стараются разделить гуи от логики программы.

где и как объявить разделяемые переменные, чтобы не было ошибок памяти, при конкурирующих потоках?

Очевидно, не использовать разделяемые переменные, а использовать IPC, например, ZeroMQ, у которого есть неплохой биндинг для Qt (nzmqt).

1)ГУИ-поток; 2)поток обработки №1; 3) поток обработки №2;

все три потока интенсивно ИСПОЛЬЗУЮТ и ИЗМЕНЯЮТ разделяемые переменные, которые представляют собой контейнеры содержащие «сложные» указатели на объекты классов и различные массивы с данными.

вопрос:
где и как объявить разделяемые переменные, чтобы не было ошибок памяти, при конкурирующих потоках?

Посмотри на предмет использования паттерна Singleton (Одиночка). Он решит тебе проблему размещения данных. А мьютексы обеспечат синхронизацию переменных/объектов от одновременного доступа из потоков.

Посмотри на предмет использования паттерна Singleton (Одиночка). Он решит тебе проблему размещения данных

И добавит проблемы с многопоточностью, если приготовить неправильно.

class Data
{
  Mutex mutex_;
  ...
 public:
  void change_prop1(...) {
    MutexLocker m(mutex_);
    ...
  }
  void change_prop2(...) {
    MutexLocker m(mutex_);
    ...
  }
  ...
};

class Thread1;
class Thread2;
class MainWidget
{
  Data data_;
  Thread1 *t1_;
  Thread2 *t2_;
 public:
   MainWidget() 
     :data_(),
     t1_(new Thread1(this, data_)),
     t2_(new Thread2(this, data_)) {}
};

как-то так

singleton это то же самое, что и статический чего-то там. дизейн ущербен по определению.

Данные вынести в ОТДЕЛЬНУЮ библиотеку. Никак не связывать с формами и другими визульными объектами. Покрыть тестами :) В качестве хранилища экземпляра - либо синглетон, либо просто глобальная статическая переменная.