Атомарность
От: vladserge Россия  
Дата: 14.10.04 06:47
Оценка: 2 (1)
Привет всем!

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

например так

int usingResource=false;

static bool UseResource()
   {
       atom
       {
          if( usingResource ) return;
          usingResource=true;
       }

        ....
        ....
        .....
        usingResource=false;    
     }

во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации.

В .NET кое что на эту тему появилось, я про Interlocked, но вырозительности и прозрачности использования нет
зацените сами
        //0 for false, 1 for true.
        private static int usingResource = 0;

        //A simple method that denies reentrancy.
        static bool UseResource()
        {
            //0 indicates that the method is not in use.
            if(0 == Interlocked.Exchange(ref usingResource, 1))
            {
                Console.WriteLine("{0} acquired the lock", Thread.CurrentThread.Name);
            
                //Code to access a resource that is not thread safe would go here.
            
                //Simulate some work
                Thread.Sleep(500);

                Console.WriteLine("{0} exiting lock", Thread.CurrentThread.Name);
            
                //Release the lock
                Interlocked.Exchange(ref usingResource, 0);
                return true;
            }
            else
            {
                Console.WriteLine("   {0} was denied the lock", Thread.CurrentThread.Name);
                return false;
            }
        }

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

int usingResource=false;

static bool UseResource()
   {
       atom
       {
          if( usingResource ) return;
          usingResource=true;
        }

        for(; ;);
        ....
        .....
        usingResource=false;    
     }

то зависнет только это приложение.

Просто делюсь соображениями, возможно что я не одинок.... или это велосипед и я чего то незнаю. Обсудим ?
С Уважением Сергей Чикирев
Re: Атомарность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.10.04 07:42
Оценка: 22 (2)
Здравствуйте, vladserge, Вы писали:

V> или это велосипед и я чего то незнаю


В ОО языке Active Oberon для программирования параллельных вычислений существует всего три ключевых слова ACTIVE, EXCLUSIVE и AWAIT. Ключевое слово ACTIVE используется для того чтобы различать активные объекты от обычных-пассивных объектов. Для обеспечения описанной Вами "атомарности" используются другие два слова EXCLUSIVE и AWAIT. EXCLUSIVE — как раз и гарантирует, что указанное действие должно выполниться полностью, до того как кто-то другой захочет выполнить это же самое действие, вот Вам и "атомарность":
BEGIN {EXCLUSIVE} (* changes to both x and y are atomic *)
  x := x0;  y := y0;
END;

AWAIT(Condition: BOOLEAN) — приостанавливает активность (активность = поток/процесс активного объекта) до тех пор пока не будет выполнено условие Condition.

Вот пример пассивного объекта, доступ к которому потокобезопасен:

MODULE BoundedBuffers;

TYPE
  Item* = OBJECT; (* generic object *)
  

  Buffer* = OBJECT
    VAR h, n: INTEGER;  B: ARRAY * OF Item;

    PROCEDURE Get*(): Item;
    VAR x: Item;
    BEGIN {EXCLUSIVE}
      AWAIT(n # 0); (* buffer not empty *)
      x := B[h]; h := (h+1) MOD LEN(B); DEC(n);
      RETURN x
    END Get;

    PROCEDURE Put*(x: Item);
    BEGIN {EXCLUSIVE}
      AWAIT(n # LEN(B)); (* buffer not full *)
      B[(h+n) MOD LEN(B)] := x; INC(n)
    END Put;

    PROCEDURE &Init(max: INTEGER);
    BEGIN (* initializer *)
      NEW(B, max); h := 0; n := 0
    END Init;

  END Buffer;


END BoundedBuffers.


http://bluebottle.ethz.ch/languagereport/index.html
http://www.oberon.ethz.ch/active/
http://www.oberon.ethz.ch/native/aos/
http://www.cs.inf.ethz.ch/~muller/
http://bluebottle.ethz.ch/
http://www.zonnon.ethz.ch/
Re: Атомарность
От: sereda Россия http://igorsereda.moikrug.ru
Дата: 14.10.04 08:22
Оценка: +1
Здравствуйте, vladserge, Вы писали:

V>Привет всем!


V>Неоднократно, в своей работе сталкиваюсь с необходимостю языковой конструкции которая позволяла бы указать что вот данный участок кода нужно выполнять целостно,атомарно категорически недопуская переключения потока (thread switching) в нем (внутри него).



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

Я полагаю, Вы хотите достигнуть атомарности операции. Переключение потоков здесь ни при чем. Просто надо обеспечить условия для того, чтобы другой поток не "увидел" результаты вашей операции, пока она до конца не выполнилась.

В Java для этого используются мониторы и ключевое слово synchronized.

Переписывая Ваш пример:

boolean usingResource = false;
Object lock = new Object();

static boolean useResource() {
  synchronized (lock) {
    if (usingResource)
      return false;
    usingResource = true;
  }
  ....
  ....

  synchronized (lock) {
    usingResource = false;
  }
}



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

По моему, очень удобная и высокоуровневая конструкция, учитывая дополнительные возможности Java с ключевым словом synchronized.
Re: Атомарность
От: WolfHound  
Дата: 14.10.04 09:02
Оценка: +1
Здравствуйте, vladserge, Вы писали:

V>В .NET кое что на эту тему появилось, я про Interlocked, но вырозительности и прозрачности использования нет

V>зацените сами
Ну это появилось не в .НЕТ, а гораздо раньше

InterlockedExchange
The InterlockedExchange function atomically exchanges a pair of values. The function prevents more than one thread from using the same variable simultaneously.

If you are exchanging pointer values, this function has been superseded by the InterlockedExchangePointer function.

LONG InterlockedExchange(
  LPLONG Target, // value to exchange
  LONG Value     // new value
);

Parameters
Target
[in/out] Pointer to the value to exchange. The function sets this variable to Value, and returns its prior value.
Value
[in] Specifies a new value for the variable pointed to by Target.
Return Values
The function returns the initial value pointed to by Target.

Remarks
The functions InterlockedExchange, InterlockedCompareExchange, InterlockedDecrement, InterlockedExchangeAdd, and InterlockedIncrement provide a simple mechanism for synchronizing access to a variable that is shared by multiple threads. The threads of different processes can use this mechanism if the variable is in shared memory.

The variable pointed to by the Target parameter must be aligned on a 32-bit boundary; otherwise, this function will fail on multiprocessor x86 systems and any non-x86 systems.

Requirements
Windows NT/2000: Requires Windows NT 3.5 or later.
Windows 95/98: Requires Windows 95 or later.
Header: Declared in Winbase.h; include Windows.h.
Library: Use Kernel32.lib.

See Also
Synchronization Overview, Synchronization Functions, Interlocked Variable Access, InterlockedCompareExchange, InterlockedDecrement, InterlockedExchangeAdd, InterlockedExchangePointer, InterlockedIncrement

Built on Thursday, October 12, 2000Requirements
Windows NT/2000: Requires Windows NT 3.5 or later.
Windows 95/98: Requires Windows 95 or later.
Header: Declared in Winbase.h; include Windows.h.
Library: Use Kernel32.lib.
See Also
Synchronization Overview, Synchronization Functions, Interlocked Variable Access, InterlockedCompareExchange, InterlockedDecrement, InterlockedExchangeAdd, InterlockedExchangePointer, InterlockedIncrement


V>понятно, что найдуться чайники которые начнут внутрь атомарного кода пихать длительные операции приводя к завесалову всей системы. Но с этим можно бороться, например подразумевая что НЕпереключения потоков внутри атомарного кода происходит только в контексте приложения, а не всей системы. Таким образом если некто напишет ахинею типа

Гм. ИМХО мысль не плохая. Но ИМХО придется вводить поддержку на уровне операционной системы.
Тут есть форум в котором можно задать вопросы ребятам из Майкрософт... спроси у них.
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Атомарность
От: WolfHound  
Дата: 14.10.04 09:02
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>EXCLUSIVE — как раз и гарантирует, что указанное действие должно выполниться полностью, до того как кто-то другой захочет выполнить это же самое действие, вот Вам и "атомарность":

СГ>
СГ>BEGIN {EXCLUSIVE} (* changes to both x and y are atomic *)
СГ>  x := x0;  
(* те в этом месте поток может переключиться? *)
СГ>  y := y0;
СГ>END;
СГ>

Если да то что мешает другому потоку обратиться к рассогласованым x, y?
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Атомарность
От: vladserge Россия  
Дата: 14.10.04 09:16
Оценка:
Здравствуйте, sereda, Вы писали:

S>Здравствуйте, vladserge, Вы писали:


V>>Привет всем!


V>>Неоднократно, в своей работе сталкиваюсь с необходимостю языковой конструкции которая позволяла бы указать что вот данный участок кода нужно выполнять целостно,атомарно категорически недопуская переключения потока (thread switching) в нем (внутри него).



S>Видите ли, переключение потока — это системная операция, и хорошо бы, чтобы язык высокого уровня не имел к ней доступа. Это все равно что требовать, чтобы вот на этом участке кода процессор не переключался на другой процесс.


именно этого и хочется, я ж ясно выразился, как впрочем и для чего.


S>Я полагаю, Вы хотите достигнуть атомарности операции. Переключение потоков здесь ни при чем. Просто надо обеспечить условия для того, чтобы другой поток не "увидел" результаты вашей операции, пока она до конца не выполнилась.


дивно, а не проще ли систнмному диспетчеру процессов обнаружить что он внутри атомарного блока и не деактивировать текущий процесс и переключаться на доругой. Это ОЧЕНЬ ДОРОГО !!!!!!


S>В Java для этого используются мониторы и ключевое слово synchronized.


нужно будет записать, а то забуду есть такие бины и по их спецификации ВСЕметоды обязательно должны бать synchronized....Больших тормозов мир програмирования незнает.


S>По моему, очень удобная и высокоуровневая конструкция, учитывая дополнительные возможности Java с ключевым словом synchronized.


Спасибо за ответ, но на будущее просьба, до конца читать пост на который Вы отвечаете. Я ж ведь не графоман какой, то и когда пишу буквально

во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации.

то это я делаю специально для Вас.
С Уважением Сергей Чикирев
Re[2]: Атомарность
От: vladserge Россия  
Дата: 14.10.04 09:22
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, vladserge, Вы писали:


V>>В .NET кое что на эту тему появилось, я про Interlocked, но вырозительности и прозрачности использования нет

V>>зацените сами
WH>Ну это появилось не в .НЕТ, а гораздо раньше

Ошибся хотел написать В например .NET кое что на эту тему есть далее по тексту....

V>>Гм. ИМХО мысль не плохая. Но ИМХО придется вводить поддержку на уровне операционной системы.

Ну я тут не о трудностях, а об удобстве и необходимости фичи рассуждаю.

V>>Тут есть форум в котором можно задать вопросы ребятам из Майкрософт... спроси у них.


Пока ясовсем неуверен, что это кому нибудь, кроме меня может быть интересно. а там .... будем посмотреть.

PS спасибо за ответ
С Уважением Сергей Чикирев
Re: Атомарность
От: Кодт Россия  
Дата: 14.10.04 09:30
Оценка: 15 (4)
Здравствуйте, vladserge, Вы писали:

V>во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации.


... но, в отличие от мониторов/крит.секций, не гарантирует целостности.
Пример:
int x = 1, y = 2;

void sum_thread() { printf("%d, %d", x, y); }

void toggle_thread() { atom { swap(x,y); } }

Запустили оба потока.
Первый: взял x... (и был вытеснен)
Второй: обменял x,y
Первый: взял y и напечатал.
Что мы видим? Правильно: 1,1

Поскольку мониторы очень и очень распространены, специально для этого любая нормальная ОС содержит легковесные средства их реализации.
Например, под виндоузом есть два мутекса — "дорогой" HMUTEX и "дешёвый" CRITICAL_SECTION.
Первый — это объект ядра, все операции над ним требуют проваливания в нулевое кольцо.
Второй — объект пользователя, сделанный чуть ли не на InterlockedExchange() / Sleep().
Перекуём баги на фичи!
Re[3]: Атомарность
От: sereda Россия http://igorsereda.moikrug.ru
Дата: 14.10.04 09:36
Оценка:
Здравствуйте, vladserge, Вы писали:

V>Спасибо за ответ, но на будущее просьба, до конца читать пост на который Вы отвечаете. Я ж ведь не графоман какой, то и когда пишу буквально


V>во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации.


V>то это я делаю специально для Вас.



Спасибо Вам за то, что Вы делаете специально для меня. Я прочитал Ваш пост еще раз внимательно. Конечно, очевидно, что в цитируемой Вами фразе Вы имели в виду и synchronized в Java. Покорнейше прошу прощения за то, что не заметил сразу, и что купился на предложение обсудить вопрос.


По теме. Если вы хотите сэкономить на context switching'e, то надо от языков требовать поддержки атомарных команд процессора вроде TestAndSet. Блокировать context switching грубой силой — это значит рисковать из-за ошибок нарушить работу не только приложения, но и всей операционки. Не думаю, что этот риск оправдан соображениями производительности.
Re[2]: Атомарность
От: vladserge Россия  
Дата: 14.10.04 09:49
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, vladserge, Вы писали:


V>>во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации.


К>... но, в отличие от мониторов/крит.секций, не гарантирует целостности.

К>Пример:
К>
К>int x = 1, y = 2;

К>void sum_thread() { printf("%d, %d", x, y); }

К>void toggle_thread() { atom { swap(x,y); } }
К>

К>Запустили оба потока.
К>Первый: взял x... (и был вытеснен)
К>Второй: обменял x,y
К>Первый: взял y и напечатал.
К>Что мы видим? Правильно: 1,1

Ну так не честно , этот пример, из категории "...а если бы он вез патроны!!!???" .

исправить его достаточно несложно


int x = 1, y = 2;

void sum_thread() { atom {printf("%d, %d", x, y)}; }

void toggle_thread() { atom { swap(x,y); } }


или, если уж к примеру printf — длительная операция.

int x = 1, y = 2;

void sum_thread() 
{


int X, Y;


  atom
    {
      X=x;
      Y=y
    }
 
   printf("%d, %d", X, Y); 
}

void toggle_thread() { atom { swap(x,y); } }





К>Поскольку мониторы очень и очень распространены, специально для этого любая нормальная ОС содержит легковесные средства их реализации.


При любых самых разлегковестных средствах переключение потока на несколько тактов позже жестко запланированого выиграет (в смысле наклодных расходов). и вот еще одна деталь, у этой модели небывает дедлоков , (ну или как там по русски?)
С Уважением Сергей Чикирев
Re[4]: Атомарность
От: vladserge Россия  
Дата: 14.10.04 09:58
Оценка:
Здравствуйте, sereda, Вы писали:

S>Здравствуйте, vladserge, Вы писали:


V>>Спасибо за ответ, но на будущее просьба, до конца читать пост на который Вы отвечаете. Я ж ведь не графоман какой, то и когда пишу буквально


V>>во многих местах это позволило бы отказаться от иных, весьма накладных, средств синхронизации.


V>>то это я делаю специально для Вас.



S>Спасибо Вам за то, что Вы делаете специально для меня. Я прочитал Ваш пост еще раз внимательно. Конечно, очевидно, что в цитируемой Вами фразе Вы имели в виду и synchronized в Java. Покорнейше прошу прощения за то, что не заметил сразу, и что купился на предложение обсудить вопрос.



S>По теме. Если вы хотите сэкономить на context switching'e, то надо от языков требовать поддержки атомарных команд процессора вроде TestAndSet. Блокировать context switching грубой силой — это значит рисковать из-за ошибок нарушить работу не только приложения, но и всей операционки. Не думаю, что этот риск оправдан соображениями производительности.


Да простят меня модераторы за частое самоцетирование, ну а что делать?

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


А по поводу возможностей и "рисковать из-за ошибок нарушить работу не только приложения, но и всей операционки"
откомпилируйте и запустите
public static void main(String args[])
    {
    
     for(;;);
    
    }

понятно, что спички детям не игрушка.
С Уважением Сергей Чикирев
Re[3]: Атомарность
От: WolfHound  
Дата: 14.10.04 10:09
Оценка:
Здравствуйте, vladserge, Вы писали:

V>Ну я тут не о трудностях, а об удобстве и необходимости фичи рассуждаю.

Дело в том что если обсуждать фичу то нужно выяснить соотношение необходимость/цена. И в этом свете нужно обсудить сложности.

V>Пока ясовсем неуверен, что это кому нибудь, кроме меня может быть интересно. а там .... будем посмотреть.

Тут надо подумать о целесообразности этого. Ведь в сущьности это всеголишь глобальный(в приделах процесса)мутекс.
Хотя если производительность этого мутекса будет сравнима с Interlocked функциями и этот мутекс будет всегда инициализирован то это может быть полезно.
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Атомарность
От: vladserge Россия  
Дата: 14.10.04 10:25
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, vladserge, Вы писали:


V>>Ну я тут не о трудностях, а об удобстве и необходимости фичи рассуждаю.

WH>Дело в том что если обсуждать фичу то нужно выяснить соотношение необходимость/цена. И в этом свете нужно обсудить сложности.
Мне всеже кажется для начала нужно понять насколько это "фкусно", прежде чем стоять за этим в очередь.

V>>Пока ясовсем неуверен, что это кому нибудь, кроме меня может быть интересно. а там .... будем посмотреть.

WH>Тут надо подумать о целесообразности этого. Ведь в сущьности это всеголишь глобальный(в приделах процесса)мутекс.

мутекс. правда Вы так считаете? мож какое другое слово?


WH>Хотя если производительность этого мутекса будет сравнима с Interlocked функциями и этот мутекс будет всегда инициализирован то это может быть полезно.


ничего не понимаю
С Уважением Сергей Чикирев
Re: Атомарность
От: GlebZ Россия  
Дата: 14.10.04 10:30
Оценка:
Здравствуйте, vladserge, Вы писали:

Товарищ, вы отстаете от моды. Сейчас модно защищать объекты, а не просто куски кода. Наглядный пример из NET:


class A
{
.....
property Result prop
{
//изменения и работа с внутренней стороны
get{lock(this){....}}
set{lock(this){....}}
}
....
}

class B
{
...
A _a;
void aaa()
{
lock(_a)
{
.....
//Изменения с внешней стороны
....
}
}
...
}


В результате, есть ГАРАНТИЯ правильной синхронизации объекта как внутри, так и снаружи. Защищаются именно данные а не действия над ним (и ессно в разумной степени).
Защита какой-то отдельной процедуры практически никогда не нужно, и самое главное вредно. У тебя нет никакой гарантии, что при дальнейшем развитии не будет написана другая процедура работающая с этими данными.

Была одна какая-то интересная книжка Рихтера (не помню названия, давно читал), где он примерно описывал работу объектов синхронизации для Win API.

С уважением, Gleb.
Re[3]: Атомарность
От: Кодт Россия  
Дата: 14.10.04 10:39
Оценка:
Здравствуйте, vladserge, Вы писали:

V>Ну так не честно , этот пример, из категории "...а если бы он вез патроны!!!???" .

V>исправить его достаточно несложно

Ну и что получаем? Всё тот же монитор.

К>>Поскольку мониторы очень и очень распространены, специально для этого любая нормальная ОС содержит легковесные средства их реализации.


V>При любых самых разлегковестных средствах переключение потока на несколько тактов позже жестко запланированого выиграет (в смысле наклодных расходов). и вот еще одна деталь, у этой модели небывает дедлоков , (ну или как там по русски?)


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

Собственно, Interlocked операции и используют мутекс, только аппаратный.
Перекуём баги на фичи!
Re[5]: Атомарность
От: Кодт Россия  
Дата: 14.10.04 10:45
Оценка:
Здравствуйте, vladserge, Вы писали:

WH>>Тут надо подумать о целесообразности этого. Ведь в сущьности это всеголишь глобальный(в приделах процесса)мутекс.


V>мутекс. правда Вы так считаете? мож какое другое слово?


Именно мутекс как абстракция многозадачного программирования.
Какая именно реализация этого мутекса — на HMUTEX, на CRITICAL_SECTION, на семафорах — это уже нюансы. (Мне однажды пришлось реализовывать на трубках — pipe — потому что API VxWorks не поддерживает групповых операций над иными синхрообъектами).
Перекуём баги на фичи!
Re: Атомарность
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.10.04 10:48
Оценка: 1 (1) +1
Здравствуйте, vladserge, Вы писали:

V>Привет всем!


V>Неоднократно, в своей работе сталкиваюсь с необходимостю языковой конструкции которая позволяла бы указать что вот данный участок кода нужно выполнять целостно,атомарно категорически недопуская переключения потока (thread switching) в нем (внутри него).

А ты уверен, что возникает именно такая необходимость? Дело в том, что обычно проблемы одновременного доступа относятся скорее не к атомарности какого-то фрагмента кода, а к атомарности какого-то фрагмента данных. И именно для защиты данных вводятся всякие примитивы синхронизации. Запрет на исполнение вообще любого кода во время исполнения твоего фрагмента просадит производительность. Особенно в многопроцессорных системах. Поэтому код размечают примитивами, которые позволяют выделить участки, несовместимые между собой.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Атомарность
От: vladserge Россия  
Дата: 14.10.04 13:22
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, vladserge, Вы писали:


V>>Привет всем!


V>>Неоднократно, в своей работе сталкиваюсь с необходимостю языковой конструкции которая позволяла бы указать что вот данный участок кода нужно выполнять целостно,атомарно категорически недопуская переключения потока (thread switching) в нем (внутри него).

S>А ты уверен, что возникает именно такая необходимость? Дело в том, что обычно проблемы одновременного доступа относятся скорее не к атомарности какого-то фрагмента кода, а к атомарности какого-то фрагмента данных. И именно для защиты данных вводятся всякие примитивы синхронизации. Запрет на исполнение вообще любого кода во время исполнения твоего фрагмента просадит производительность.

Это почему же?????????? А я утверждаю что все произойдет с точностью до НАОБОРОТ.
Производительность возрастет и вот почему. Вместо выполнения совокупности дорогостоящих процедур синхронизации, код просто эксклюзивно продолжает выполняться в плоть до выхода из атомарной секции. Порошу заметить ВЫПОЛНЯТЬСЯ, не блокироваться, а выполняться!

В каком месте будет падение производительности ????
С Уважением Сергей Чикирев
Re[3]: Атомарность
От: Merle Австрия http://rsdn.ru
Дата: 14.10.04 13:57
Оценка:
Здравствуйте, vladserge, Вы писали:

V>Производительность возрастет и вот почему. Вместо выполнения совокупности дорогостоящих процедур синхронизации, код просто эксклюзивно продолжает выполняться в плоть до выхода из атомарной секции. Порошу заметить ВЫПОЛНЯТЬСЯ, не блокироваться, а выполняться!

Это получается уже кооперативная многозадачность, а не вытесняющая. И приводит это к тому, что если твой код навернулся внутри критической секции, не важно по какой причине, расхлебывать будет вся система. Последствия подобного поддхода очень хорошо были видны на примере win16, там делалось ровно так как ты описываешь...
Правда и у вытесняющей многозадачности, с блокировкой данных, есть свои подводные камни ввиде тогоже Convoy Effect'а, но с ними более-менее научились бороться...
... [ RSDN@Home 1.1.4 revision 142 ]
Мы уже победили, просто это еще не так заметно...
P. S.
От: Merle Австрия http://rsdn.ru
Дата: 14.10.04 14:01
Оценка: 35 (2)
Кстати, то, что ты называешь "атомарность", скорее стоит назвать "сериализуемость" или "изолированность"... Все-таки под атомарностью обычно понимают немного другое.
Атомарность — это если твой код либо выполняется целиком, либо не выполняется вообще. И мьютексы с семафорами и прочими блокировками здесь не спасут, если кусок кода навернется в середине выполнения, то об откате надо заботиться отдельно.
... [ RSDN@Home 1.1.4 revision 142 ]
Мы уже победили, просто это еще не так заметно...
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.