Объекты и многопоточность

[Mayor]

Как в условиях многопоточности( из-за WindProc):

1. Каждому объекту класса присвоить уникальный ID внутри класса?
2. По ID в любой момент получить указатель на объект?
3. Остановить создание объекта если их лимит для класса превышен?

[RXL]

Используй блокировки (мутексы).

[Serega]

Сделай фабрику обьектов.
И создавай их только с помощью нее, так будет проще следить.

Если интересно почитай шаблоны проектирования, существует еще несколько шаблонов, использующихся при сооздании обьектов

[ixania]

1. если обьекты твои, обьяви статическую переменную в класе, которая будет общей для всех екземпляров, для чужих можешь создать класс наследник либо рапер.

2. надо гдето и както держать список ID -> pointer to object

3. как и в первом пункте каждый клас должен иметь свой семафор, т.к. при помощи семафоров легче всего зреалзуется доступ к ресурсам

[Mayor]

Что-то сложно - похоже мне надо что-то почитать, в подобном случае вроде уже советовали Рихтера?

[Serega]

"Design Patterns" by Erich Gamma at all.

Есть на русском, называется "Шаблоны проектирования", издательство Питер.

[Mayor]

Serega, уже скачиваю ...

 Я вот тут подумал, зачем мне синхронизирующие объекты если похоже надо только синхронизировать обращение к  static переменной, неужели в Win нету API оболочки для такой инструкции процессора?

[Serega]

Что значит "неужели в Win нету API оболочки для такой инструкции процессора?" :?:
В WinApi есть обьекты синхронизации, ты их можешь использовать как тебе нужно

[ixania]

aka InterlockedIncrement and InterlockedDecrement, dlea dostupa c premenoi ID classa te ne nujno safe metodov dostupa t.k. ti peremenuiu budesi tolico chitati. Dlea ogranicenia dostupa te nusjen staticheskii semafor, cogda odna iz functii WaitFor... vernet sto semafor zaneat polnostiu snachit limit dlea clasa iscerpan  

[lapulya]

Совершенно точно можно как народ предлагает реализовать этот функционал через семафор и мъютекс, НО так делать НЕ надо, а надо как сказал серега написать фабрику классов и в начале функции create входить в критическую секцию (или использовать атомарные операции для необходимой проверки типа InterlockedIncrement... как уже кстати советовали) в конце функции выходить ... функция destroy реализуется аналогично, причем для входа и выхода из критической секции можно написать враппер типа guard который в конструкторе входит в секцию а в деструкторе выходит из нее и такой оббъект согдавать на стеке (есное дело перед обращением к критическому месту в коде).
А семафоры и мъютексы тут лучше не юзать потому, что энто объеткы ядра и работа с ними происходит СУЩЕСТВЕННО медленнее чем с критическими секциями и атомарными операции (потому что нет переключения в режим ядра)... типа вот!!!

[titov_alex]

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

Код:

UINT last_id;
CRITICAL_SECTION my_GNID_SC;

UINT GetNextID(void) {
  UINT new_id;
  
  EnterCriticalSection(&my_GNID_SC);
  new_id = last_id;
  last_id ++;
  LeaveCriticalSection(&my_GNID_SC);
  
  return new_id;
}

Разумеется, при запуске программы нужно предварительно инициализировать переменные last_id и my_GNID_SC, а перед завершением - закрыть критическую секцию.

Код:

int InitGNID(void) {
  last_id = 0;
  InitializeCriticalSection(&my_GNID_SC);
  return 0; // тут можно добавить обработку ошибки инициализации..
}

int DeinitGNID(void) {
  DeleteCriticalSection(&my_GNID_SC);
  return 0;
}

Зато, гарантированно не будет два одинаковых ID-шника обекта, так как все айдишники выделяются в одной и той же критической секции.

ПС. У меня примерно так реализован механизм выдачи ID для некоторых объектов. Хотелось бы улучшить его для выдачи _свободных_ ID, тоесть на данный момент, функция гарантировано работает только первые MAX_DWORD раз, после чего она может выдать существующий ID (при переполнении значения last_id). По идее, у меня имеется динамический массив загруженных обьектов, но как в этом массиве легче найти свободный ID - пока не придумал.. может кто-нибудь поделится соображениями?  

[ixania]

2lapulea ti prav(a) naset skorosti kriticheskih sectii, no nujna li eta skorosti v danom sluchae i budet li eta raznitsa chustvovatsa na segodneasnih masinah, plius s sektiami u tebya dopolnitelinaya peremenaya dlea podseta exemplearov cogda s semaforom budet primerno tac

if ( WaitForSingleObject (hSem, 10) == WAIT_OBJECT_0)
{
// sozdaem novii obiect
}
else
{
// ne sozdaem obiect, diapazon zaneat
}

No eto sugubo lichnoe mnenie.

2titov_alex ya viju dva varianata v tvoem sluchae, et prohojdenie diapazona ID i proverca na evo susestvovanie v masive obiectov i zanimati pervii nesusestvuiusii v masive obiectov, tak budesi zapolneati probeli, vtoroi variant eto imeti spisoc svobodnih ID, cogda ID zanimaetsa udaleai evo iz spisca, pri udalenii obiecta evo ID zanositsa obratno v spisoc svobodnih ID, takim obrazom u tebya budet pool svobodnih ID.

A mojno v cachestve ID ispolizovati adres obiecta, vedi odnovremenno ne mojet susestvovati dva obiecta s odnim i temje adresom   et idet horoso v sochetanii s semaforami t.k. ogranicenie exemplearov budet obespecheno semaforami a unikalinosti ID samoi sistemoi    t.k. cajdii obiect budet imeti unicalinii adress (et spravedlivo dlea odnovo i tovoje protesa), vot vam i ID i adres obiecta v odnom litse, tut to i voprosov netu cac po ID naiti adres obiecta .

[titov_alex]

Адрес=ID - не лучшее для меня решение, так как я определяю тип объекта по тому, в каком диапозоне лежит айдишник..
Список свободных айдишников был бы наверное интереснее в виду быстродействия, но хранить MAX_DWORD записей на мой взгляд слишком расточительно
Я склоняюсь к использованию простейшего перебора всех объектов в поисках пропущенного ID, но мне кажется, что поиск можно было бы оптимизировать..

По меньшей мере, до момента переполнения (превышения выделенного под айдишник диапозона) я вполне могу выдавать следующий ID.. А вот дальше, уже придется искать.. В принцыпе, т.к. объектов будет одновременно не так и много (несравнимо меньше, чем существующих ID-шников), можно попросту проверять, свободен ли ID, который обозначен как следующий и если нет - попробывать увеличить next_id и проверить уже его (и так, пока ID не подойдет)

Пока писал, появилась идея:
Имеем:
1. ID следующего объекта (next_id)
2. Список уже созданных объектов, причем этот список должен быть отсортирован по ID объекта (objects).

Алгоритм:
1. пробегаем список имеющихся объектов до объекта, с ID большим или равным next_id.
1.1 если нашли объект с ID>next_id, либо достигли конца списка, не найдя нужного ID => next_id свободен, назначаем его новому объекту и увеличиваем next_id на 1.
2. Иначе () - идем по списку объектов до первого пробела начиная с текущей позиции (либо с начала списка?) и этот первый попавшийся пробел назначаем ID-шником нового объекта, увеличив после этого next_id на единицу.

Можно начинать искать свободный номер и с начала списка, но мне сложно объяснить, почему мне больше нравится искать ID больше того, который указан в значении next_id (наверное, последний вариант более схож к тому, к чему я привык - ID выдаются последовательно следующий ID скорее всего будет больше предыдущего).

Для того, чтобы вообще не беспокоиться о том, занят ли next_id или нет в тот период, пока переполнения next_id за вехнюю границу допустимого диапозона, можно ввести дополнительный флаг типа befor_owerflow, и поставить его в true как только такое переполнение произойдет (скорее всего, очень не скоро   )

По всей видисмоти, так я и сделаю, т.к. моя программа будет работать в некоторых случаях безпрерывно на протяжении нескольких месяцев (в идеале - лет 8) ), а порой - 5 минут. В последнем случаем, впрочем, вообще не представляется вероятной ситуация с переполнением

Сейчас попробую реализовать эту идею в коде и помещу ее тут, если получится что-нибудь путное  

[titov_alex]

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

Вот полный (почти) код тестового проекта:

Код:

// GNID_test.cpp : Defines the entry point for the console application.
//

#include "windows.h"
#include "stdafx.h"
#include "Lists.h"
#include "conio.h"

// Критическая секция для разграничения доступа к УИНам объектов (при назначении новых УИНов)
CRITICAL_SECTION csGLOBAL_GNID;

#define __GLOBAL__MaxConnNum    16L
#define __GLOBAL__MinConnNum     1L

unsigned __int32 __GLOBAL__NextConnNum = 1;
bool             __GLOBAL__NextConnNum_Overloaded = false; // Среди занятых УИНов есть хотябы один  УИН, больше __GLOBAL__NextChanNum 

typedef struct t_connectios_uin_list {
  UINT conn_uin;
}t_connectios_uin_list;

list <t_connectios_uin_list> Connection_UINs_list;

unsigned __int32 GLOB_GetNextConnectionUIN() {
  UINT ret_val = 0;
  bool on_full_break = false;
  
  int i;
  
  ::EnterCriticalSection(&csGLOBAL_GNID);
  
  if (!__GLOBAL__NextConnNum_Overloaded) {
    ret_val = __GLOBAL__NextConnNum;
    __GLOBAL__NextConnNum ++;
    goto EXIT_CS;
  }
  
  for (i =0; i < Connection_UINs_list.size(); i++) {
    
    if (Connection_UINs_list[i].conn_uin > __GLOBAL__NextConnNum) { // УИН свободен, назначаем его
      ret_val = __GLOBAL__NextConnNum;
      __GLOBAL__NextConnNum++;
      goto EXIT_CS;
    }
    
    else if (Connection_UINs_list[i].conn_uin == __GLOBAL__NextConnNum) { // УИН занят, ищем пробел в списке
      
      // Ищем первый пробел начиная с текущей позиции в списке
      while (Connection_UINs_list[i].conn_uin == __GLOBAL__NextConnNum) {
        i++;
        __GLOBAL__NextConnNum ++;
        if (__GLOBAL__NextConnNum >= __GLOBAL__MaxConnNum) { // обрабатываем переполнение уин-а
          if (on_full_break) { // Если уже переполнялись в этот раз, все УИН-ы заняты!
            ret_val = 0; 
            goto EXIT_CS; // Выходим к концу критической секции, вернем 0, так как нет свободных УИНов (0 не входит в допустимый диапазон)
          }
          __GLOBAL__NextConnNum = __GLOBAL__MinConnNum; // будем искать начиная с минимального УИНа
          i = 0; // возвращаемся в начало списка
          on_full_break = true; // больше в этот раз переполнений быть не должно!
          __GLOBAL__NextConnNum_Overloaded = true; // Так как мы только что прошли через переполнение, скорее всего есть занятые УИНы, большие чем __GLOBAL__NextConnNum
        }
        if (i > Connection_UINs_list.size()) { // Дошли до конца списка, накопленное значение __GLOBAL__NextConnNum в списке не имеется
          ret_val = __GLOBAL__NextConnNum;
          __GLOBAL__NextConnNum ++;
          __GLOBAL__NextConnNum_Overloaded = false; // Так как выяснилось, что __GLOBAL__NextConnNum больше максимального УИНа в списке, мы можем быть уверены, что до переполнения колизий не будет
          goto EXIT_CS;
        }
      }
      // Если попали сюда, пробел найден (накопленный __GLOBAL__NextConnNum не равен текущему УИНу в списке)
      ret_val = __GLOBAL__NextConnNum;
      __GLOBAL__NextConnNum ++;
      goto EXIT_CS;
    }
    // свободный УИН пока не найден, ищем дальше...
  }
  
  // Прошли весь список УИНов, но не нашли ничего => __GLOBAL__NextConnNum свободен
  ret_val = __GLOBAL__NextConnNum;
  __GLOBAL__NextConnNum ++;

EXIT_CS:
  // Попав сюда, мы либо нашли свободный УИН, либо убедились, что его нет. ret_val содержит УИН, который мы будем назначать
  // Нам надо добавить новый УИН в список. Список должен быть отсортирован, так что вставляем сразу на его место.
  if ((ret_val>=__GLOBAL__MinConnNum)&&(ret_val<=__GLOBAL__MaxConnNum)) { // Добавлять будем только тогда, когда накопленный новый УИН лежит в допустимом диапазоне
    for (i = 0; i < Connection_UINs_list.size(); i ++) {
      // Как только найдем элемент с УИНом, больше чем ret_val, перед ним и вставляем новую запись в список занятых УИНов
      if (Connection_UINs_list[i].conn_uin > ret_val) break;
    }
    t_connectios_uin_list * rec;
    // Создаем новую запись в списке УИНов
    rec = &(Connection_UINs_list.add_num(i));
    // И пишем туда новый занятый УИН
    rec->conn_uin = ret_val;
  }
  
  if (__GLOBAL__NextConnNum >= __GLOBAL__MaxConnNum) { // Обрабатываем переполнение __GLOBAL__NextConnNum
    __GLOBAL__NextConnNum = __GLOBAL__MinConnNum;
    __GLOBAL__NextConnNum_Overloaded = true; // так как было переполнение, вполне вероятно, что имеются УИНы больше минимального!
  }
  
  ::LeaveCriticalSection(&csGLOBAL_GNID);
  return ret_val; // Новый УИН выделен и запись о нем добавлена в список занятых УИНов, либо нет свободных УИНов, если ret_val == 0
}

int GLOB_ReleaseConnectionUIN(UINT conn_uin) {
  int ret_val = -1;
  ::EnterCriticalSection(&csGLOBAL_GNID);
  for (int i = 0; i < Connection_UINs_list.size(); i++) {
    if (Connection_UINs_list[i].conn_uin == conn_uin) {
      Connection_UINs_list.kill(i);
      ret_val = 0;
      break;
    }
  }
  ::LeaveCriticalSection(&csGLOBAL_GNID);
  return ret_val;
}


int main(int argc, char* argv[]) {
	
  UINT id;
  int i;
  
  InitLists();
  ::InitializeCriticalSection(&csGLOBAL_GNID);
  
  for (i = 0; i < 1000000; i++) {
    id = GLOB_GetNextConnectionUIN();
    printf("Next UIN = %u\n", id);
    if (id == 0) {
      printf("All UINs is BUSY!!! =)\n");
      break;
    }
    if (((int)(i / 2)) * 2 == i) {
      printf("Try to delete UIN......%s\n", (GLOB_ReleaseConnectionUIN(id) == 0 ? "SUCCESS" : "ERROR"));
      printf("%i UINs last in the list...\n", Connection_UINs_list.size());
    }
  }
  
  ::DeleteCriticalSection(&csGLOBAL_GNID);
  printf("Hello World!\n");
	
  getch ();
  return 0;
}

сообственно, тут все за исключением шаблонного класса двусвязного списка произвольного доступа, имя которому list... Этот класс я написал в свое время сам, так как не мог переосилить собственную лень и освоить громадину стандартных аналогов

Так, как функция изначально писалась внутри большого проекта, то и имена соответствующие - тут выделяется УИН (равно ID, только для меня привычнее UIN - уникальный идентикафиционный номер) для соединения, поэтому тут постоянно присутствуют переменные типа NextConnNUM, но я не думаю, что это может как-то помешать..

Думаю, что перевести этот алгоритм на стандартные списки будет достаточно просто. Но, если у кого-нибудь есть желание, могу скинуть и Lists.h + Lists.cpp, в которых эта штуковина реализована, или вообще запостить на форуме (там не слишком много, но имхо этот код не вписывается в тему треда)..

[lapulya]

Все же следуя совету сереги (а главное здравому свыслу   ) я бы делал примерно так.....

Код:

const int MAX_SIZE = 5;	//	for example

class Factory
{
	CRITICAL_SECTION theGuard;

	int theFreeCount;
	int theCurrentID;

	typedef std::map<int, Object*> Objects;
	Objects theObjects;
public:
	Factory();
	~Factory();

	Object * create();
	void destroy(Object *);

	Object * find(int ID) const;
};

Factory::Factory()
{
	InitializeCriticalSection(&theGuard);

	theFreeCount = MAX_SIZE;
	theCurrentID = 0;
}

Factory::~Factory()
{
	DeleteCriticalSection(&theGuard);

	_ASSERT(theObjects.empty());
}


Object * Fcatory::create()
{
	bool success = false;
	EnterCriticalSection(&theGuard);

	if (theFreeCount > 0)
	{
		theCount--;
		int ID = ++theCurrentID;
		success = true;
	}
		
	LeaveCriticalSection(&theGuard);

	if (!success)
		return 0;

	Object * object = new Object(ID);
	theObjects.insert(Objects::value_type(ID, object));
	return object;
}

void Factory::destroy(Object *)
{
	...
}

Object * Factory::find(int ID) const
{
	...
}

создание и уничножение объектов типа Object должно происходить только посредством фабрики (т.е. посредством объекта типа Factory) можно код несколько оптимизировать по памяти чтобы дерево не юзать.... но это уже детали

[titov_alex]

2 Lapulya:

сообственно, код

Код:

    EnterCriticalSection(&theGuard); 

   if (theFreeCount > 0) 
   {
      theCount--; 
      int ID = ++theCurrentID; 
      success = true; 
   }
       
   LeaveCriticalSection(&theGuard); 

     

надо заменить на то, что есть в моем топике выше и будет самое то )))

Если внимательно приглядеться (посмотрев чуть выше, на мой пред-пред последний пост), то приведеный здесь кусок вашего кода является неким аналогом приведенному мною там куска кода.

Предложенные "методы" на самом деле преследуют совершенно разные задачи и вполне могут работать вместе.  

Просто, я предлагал как организовать выдачу уникальных УИНов в многопоточной программе, а предложенный вами код направлен на упорядочивание процесса создания объектов. Если их объединить, то получится фабрика объектов, выдающая каждому новому объекту гарантировано свободный уникальный УИН, если таковой имеется.

[lapulya]

ixania, на счет этого

nujna li eta skorosti v danom sluchae

скорость она всегда нужна (зачем заведомо делать медленнее, если быстрый вариант напрашивается сам собой)
а по поводу этого

budet li eta raznitsa chustvovatsa na segodneasnih masinah

какая машина будет использована для работы этой приклады не уточнялось (может PocketPC? А там ресурсы сильно ограничены), не уточнялись объемы ресурсов отожранных у системы другим работающим софтом и наконец из танного описания задачи никак нельзя оценить объемы данной (разрабатываемой) приклады.... а вдруг она немеряно сложна и очень требовательна к ресурсам и плюс к этому открывает 10000 потоков (причем если потоков более 255 чтоли... точно не помню... то твое решение не подойдет) для работы с этими объектами....

а вот это заявление считаю просто не серьезным....

plius s sektiami u tebya dopolnitelinaya peremenaya dlea podseta exemplearov cogda

его я считаю просто не серьезным.... веть реализация и поддержка семафора пусть не в самой проге а в библиотеках операционной системы отжирает ну просто невпупенные ресурсы памяти (чего стоит только один дискриптор объекта ядра)!!!!

[lapulya]

titov_alex, я посто призывал к структурированию и гибкости и плюс ко всему, к отказу в данной задаче, от использования для синхронизации потоков объектов ядра, а по поводу функционала вашего кода я замечаний и не делал, хотя если честно... то по оформлению .... оооочень громоздко, оооочень тяжело читаемо... особенно для постов в форум...

[ixania]

2lapulea

скорость она всегда нужна (зачем заведомо делать медленнее, если быстрый вариант напрашивается сам собой)
а по поводу этого

Naprimer dlea citabelinosti i prostoti coda  

какая машина будет использована для работы этой приклады не уточнялось (может PocketPC? А там ресурсы сильно ограничены), не уточнялись объемы ресурсов отожранных у системы другим работающим софтом и наконец из танного описания задачи никак нельзя оценить объемы данной (разрабатываемой) приклады.... а вдруг она немеряно сложна и очень требовательна к ресурсам и плюс к этому открывает 10000 потоков (причем если потоков более 255 чтоли... точно не помню... то твое решение не подойдет) для работы с этими объектами....

Vot poetomu bolee resursoemkie resenia ne nad otbrasivati...

его я считаю просто не серьезным.... веть реализация и поддержка семафора пусть не в самой проге а в библиотеках операционной системы отжирает ну просто невпупенные ресурсы памяти (чего стоит только один дискриптор объекта ядра)!!!!

No ya je ne utverjdal sto semafor zanimaet menise mesta, prosto sitaiu sto realizatia na semaforah prose i lehche v soprovojdenii, bolise peremenih bolishe putanitsi, tut conesno delo vkusa is konkretnoi situatii, et programmeru resati kak delati bistrii i neresursoemkii kod, ili malenkii i chitabelinii. Pravda inogda udaetsa sochitati vse eti kacestva odnovemeno, no kak pokazivaet praktika vsegda nado chemto jertvovati libo prostotoi koda libo resursami.

P.S. Ya sitaiu sto neseriesnim kakraz yavleaetsa fact sto beretsa vo vnimanie toliko skorosti i resursi, nikto ne upominaet pro sami dorogostoyasie etapi: soprovojdenie i testirovanie. Nu a problemu skorosti i rsursov dumaiu mojno ostaviti naprimer Intelu, on ih ocheni horosho resaet v poslednee vremea. Zadaitesi voprosom sto doroje v vasem sluchae vremea potrachenoe na soprovojdenii i lovle bagov ili pau metrov pameati  

[lapulya]

ixania, если думать только об уменьшении строчек кода и количестве переменных, а не о скорости выполнения и занимаемых ресурсах, ка лучше вообще не писать на WIN API, а к С++ и близко не подходить, а юзать Delphi,  C# или VB... Этоя не в обиду  просто если используется С++, то программиста интересует как раз скорость и память + гибкость, простота масштабирования, модульность и т.д. ... вот! 8)  .... ааа а вообщето меня завут - lapulya :oops: .....

[ixania]

diko izvineaiusi sto ne prospelil tvoi nik pravelino  , poimi menya pravelino ya ne protiv skorosti i ekonomii resursov, sto ti ponimaesi pod gibkostiu i modulinostiu, ya ponimaiu: mastabiroemosti, universalinosti i horosaya granylearnosti. No eto ne vsegda prosto sochitati so skorostiu. Kakoi kod lehche mastabirovati i adaptiorvati, mensii v raznere i prose v chtenii, ili polnii bardak vo imea skorosti? I stoto ti putaesi zdesi sveazivaya mastabiruemosti so scorostiu, ne viju nikakoi sveazi, mojno sozdati ocheni bistrii i ploho mastaburemii cod. Programista ponyatno sto interesuet, a vot skaji mne sto interesuet end usera, ili mojet ya ne prosledil ideiu topika i zdesi obsujdaiutsa programi dlea programistov?

[lapulya]

Да ладно, хватит бадаться.... какой-то беспредметный разговор пошел и от темы мы ушли. Если я был не прав, прошу великодушно простить, а тему пора закрывать...

[ixania]

nu... pofilosoftovali nemnogo, i sto takova   , vedi v spore rojdaetsa istina