- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
volatile void* AllocatedMemory;
int AllocateMemoryThread(const int size)
{
char buffer[size];
AllocatedMemory=(void*)buffer;
AllocatingDone.Signal();
Sleep(INFINITY);
return 0;
};
...
void* MAlloc(const int size)
{
CriticalSection.Lock();
if( !CreateThread(AllocateMemoryThread,true,size,0) )
return NULL;
AllocatingDone.Wait();
const void* AllocatedBuffer=AllocatedMemory;
CriticalSection.UnLock();
return AllocatedBuffer;
};
CriticalSection - критическая секция.
AllocatingDone - какой-то семафор.
Вообще не могу понять код. Что он этим хотел сказать...
Ну а чтобы буфер не смысло надо повесить процедуру. Просто охуенно.
Помоему довольно надёжный способ. Даже объекты синхронизации чел прекрутил.
*прикрутил
*буфер
*здесь
*прикрутил
*по-моему
*адрес
*буфер
Это я наговнокодил. :-D
Похоже, что это альтернатива стандартному malloc.
интересно, на что местное free() похоже :)
код ахуителен, осталось дождаться пока закончится место в стэке.
ну это я, как бы, догадываюсь :)
просто раз тут такой malloc(), то free() бы тоже посмотреть хотелось.
> осталось дождаться пока закончится место в стэке.
для каждого треда свой стек имеется
мне более интересно, как вот такое "char buffer[size];" компилится...
А вообще в С++ такое нифиг не нужно, есть ведь _alloca (_malloca/_freea) - она делает тоже самое, что и должен делать код в данном примере - выделять неизвестное при компиляции число байт на стеке. Автор видимо про это не знал.
если так, то, Господи, сделай, чтобы такие потом на работу не устраивались...
Идёт CriticalSection.Lock();
А затем:
if( ... )
return NULL;
Одно выполнение условия и выделять память будет невозможно.
Sleep(INFINITY); длится около 29 дней, а после поток возобновит свою работу. Выходит по прошествии этого времени память самоосвободится. :D