Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   подписка   модер. 
От: 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: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Сергей Губановhttp://moikrug.ru/users/P628059486/
Дата: 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: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: seredahttp://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: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: WolfHound rsdn 
Дата: 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]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: WolfHound rsdn 
Дата: 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]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: vladserge 
Дата: 14.10.04 09:16
Здравствуйте, sereda, Вы писали:

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


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


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



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


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


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


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


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


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


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


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

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

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

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


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

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

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

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

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

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


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

PS спасибо за ответ
С Уважением Сергей Чикирев
Re: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Кодт rsdn 
Дата: 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]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: seredahttp://igorsereda.moikrug.ru
Дата: 14.10.04 09:36
Здравствуйте, vladserge, Вы писали:

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


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


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



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


По теме. Если вы хотите сэкономить на context switching'e, то надо от языков требовать поддержки атомарных команд процессора вроде TestAndSet. Блокировать context switching грубой силой — это значит рисковать из-за ошибок нарушить работу не только приложения, но и всей операционки. Не думаю, что этот риск оправдан соображениями производительности.
Re[2]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: 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]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: 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]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: WolfHound rsdn 
Дата: 14.10.04 10:09
Здравствуйте, vladserge, Вы писали:

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

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

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

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

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


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

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

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

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

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


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


ничего не понимаю
С Уважением Сергей Чикирев
Re: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: 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]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Кодт rsdn 
Дата: 14.10.04 10:39
Здравствуйте, vladserge, Вы писали:

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

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

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

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


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


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

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

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


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


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

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


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

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

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


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


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

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

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

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

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

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

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

WH>Гм. ИМХО мысль не плохая. Но ИМХО придется вводить поддержку на уровне операционной системы.
WH>Тут есть форум в котором можно задать вопросы ребятам из Майкрософт... спроси у них.
Так есть в Win API такое средство, называется CRITICAL_SECTION.
У меня появилось смутное сомнение, что здесь везде подразумевается Java, и, соответвенно, ведется разговор слепого с глухим.

С уважением, Gleb.
Re[4]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Кодт rsdn 
Дата: 14.10.04 16:20
Здравствуйте, Merle, Вы писали:

M>Правда и у вытесняющей многозадачности, с блокировкой данных, есть свои подводные камни ввиде тогоже Convoy Effect'а, но с ними более-менее научились бороться...


А что такое convoy effect?
Перекуём баги на фичи!
Re[5]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Merle rsdnhttp://rsdn.ru
Дата: 14.10.04 20:10
Оценка:40 (1)
Здравствуйте, Кодт, Вы писали:

К>А что такое convoy effect?

Кажется правильнее все-таки Convoy Phenomena, а может и то и то верно, убей байт — не помню, но не важно...
Суть явления в следующем: допустим какой-то поток блокировал некий ресурс и давай его всячески пользовать, но тут его квант времени истек, а закончить работу он не успел. Пришел диспетчер потоков и передал управление другому потоку, которому так же нужен этот же ресурс. Но этот другой поток захватить этот ресурс уже не может, так как предыдущий блокировку снять не успел, и все отпущенное время проводит в бесцельном ожидании... И все остальные потоки, которым нужен этот ресурс, так же тихо курят, пока управление по цепочке опять не перейдет к потоку владельцу ресурса... И так продолжается до тех пор, пока не снимется блокировка. В пинципе напоминает дедлок, но отличается от него в лучшую сторону тем, что Convoy может сам рассосатья, когда спадает нагрузка, правда от этого не на много легче.
Метод борьбы с этим явлением довольно прост, надо засатвить поток, при обнаружения того, что нужный ресурс уже заблокирован кем-то другим, самому передавать управление дальше по цепочке, не дожидаясь окончания своего кванта.
Вообще классической по данному вопросу считается статья Дж. Грэя со товарищи, "The Convoy Phenomena", аж 79 года рождения (статья), но в открытом доступе мне ее, к сожалению, найти не удалось..
(Если интересно, можно Синклера потерзать, может быть у него остался аккаунт на http://portal.acm.org, там она есть)
... [RSDN@Home 1.1.4 revision 142]
Мы уже победили, просто это еще не так заметно...
Re: P. S. в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: vladserge 
Дата: 15.10.04 00:37
Здравствуйте, Merle, Вы писали:

M>Кстати, то, что ты называешь "атомарность", скорее стоит назвать "сериализуемость" или "изолированность"... Все-таки под атомарностью обычно понимают немного другое.


Я подразумеваю только то что подразумевает микрософт описывая Interlocked Class


Provides atomic operations for variables that are shared by multiple threads.

и далее

The Exchange method atomically exchanges the values of the specified variables. The CompareExchange method combines two operations: comparing two values and storing a third value in one of the variables, based on the outcome of the comparison. The compare and exchange operations are performed as an atomic operation.



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

Я же об этом ни слова не говорил.

цитирую еще один ваш довод

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


ничего не получается даже рядом не стояло.

да простят меня модераторы вынужден себя процитировать еще раз

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

млин все начинают лезть в такие дебри, вспоминать странные аналогии, а просто прочитать до конца сил ненаходят
откровенно говоря думал что получится более конструктивное обсуждения с попытками поняв мною написанное приложить к задачам сегодняшнего дня, взвесить плюсы и минусы. именно понимание того что могут возникнуть ИНЫЕ взгляды на предложенный механизм, сподвигнули меня написать об этом.
С Уважением Сергей Чикирев
Re[3]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Sinclair rsdnhttp://www.parallels.com/automation/operations/
Дата: 15.10.04 03:41
Оценка:14 (1)
Здравствуйте, vladserge, Вы писали:

V>В каком месте будет падение производительности ????

В очень простом: никакой другой код не может исполняться во время исполнения твоего. Разве это не очевидно? Все остальные потоки в блокируются. Независимо от того, с чем они сейчас работают. Если ты ограничиваешь область действия этой блокировки пределами процесса, то ситуация будет хотя бы не слишком катастрофической.
Так вот, Interlocked-операции являются реализацией именно твоей идеи. И именно из-за того, что использование "настоящих" примитивов синхронизации для них слишком дорого — у нас есть гарантия, что время удержания блокировки очень коротко.
Но вот в чем проблема: шедулер работает на уровне потоков, а не процессов. То, что ты предлагаешь, означает изменение алгоритма шедулера для учета заблокированности потоков в пределах процесса, при этом отдать управление в поток другого процесса все еще можно. Совершенно неочевидно, что это даст какие-то преимущества. Усложнение шедулера может стоить дороже тактов, выигранных на отказе от критических секций.
Впрочем, ты можешь получить аналогичный эффект при использовании фиберов. Там весь шедулинг осуществляется вручную. Они как раз сделаны для тех, кому накладные расходы на многопоточность мешают спать.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Кодт rsdn 
Дата: 15.10.04 07:09
Здравствуйте, Merle, Вы писали:

M>Метод борьбы с этим явлением довольно прост, надо засатвить поток, при обнаружения того, что нужный ресурс уже заблокирован кем-то другим, самому передавать управление дальше по цепочке, не дожидаясь окончания своего кванта.


Дык, вроде бы все так и делают, кроме отморозков. Любая функция захвата ресурса с ненулевым таймаутом приводит к переключению. А заниматься, простите, онанизмом вида
while(!take(semaphore, 0)) {}

нафиг надо?
Перекуём баги на фичи!
Re[6]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Кодт rsdn 
Дата: 15.10.04 07:13
Здравствуйте, Merle, Вы писали:

M>(Если интересно, можно Синклера потерзать, может быть у него остался аккаунт на http://portal.acm.org, там она есть)


Вот линк на статью, теперь дело за аккаунтом...
The convoy phenomenon
Mike Blasgen, Jim Gray, Mike Mitoma, Tom Price
April 1979
ACM SIGOPS Operating Systems Review, Volume 13 Issue 2
Перекуём баги на фичи!
Re[2]: P. S. в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Merle rsdnhttp://rsdn.ru
Дата: 15.10.04 07:13
Здравствуйте, vladserge, Вы писали:

V>Я подразумеваю только то что подразумевает микрософт описывая Interlocked Class


Не очень понимаю, что подразумевает под этим MS, главное чтобы мы подразумевали под этим одно и тоже...

V>Когда Вы писали "Атомарность — это если твой код либо выполняется целиком, либо не выполняется вообще."

V>Вы, вероятно имели ввиду другое понятие — трансакционность.
Нет, я имел ввиду именно атомарность.

V>Трансации именно так себя и ведут.

Правильно, а теперь давайте внимательно посмотрим, что такое транзакция. По определению транзакция это группа операций, которая обладает свойствами ACID — Атомарности (Atomicity), Согласованности(Concistency), Изолированности (Isolation), Устойчивости (Durability)

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

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

V>ничего не получается даже рядом не стояло.

Стояло, это именно оно и есть.

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

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

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

Спокуха на лице... Все все внимательно читают и прекрасно понимают.

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

Вот они иные взгляды и есть, кто ж виноват, что они не всегда устраивают...
... [ RSDN@Home 1.1.4 revision 142 ]
Мы уже победили, просто это еще не так заметно...
Re[3]: Не волнуйтесь, всё чики-пуки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Сергей Губановhttp://moikrug.ru/users/P628059486/
Дата: 15.10.04 07:21
Здравствуйте, WolfHound, Вы писали:


WH>Если да то что мешает другому потоку обратиться к рассогласованым x, y?


Не забывайте, что в Active Oberon нет таких понятий как поток или процесс, а есть понятие активности (активного объекта). Переменные x и y — есть приватные переменнные объекта и изменять их можно только посредством методов объекта, а эти методы программист должен пометить директивой {EXCLUSIVE}, и все чики-пуки!

BEGIN {EXCLUSIVE}
x := x0; y := y0
END
блок выполняется "целиком" и "сразу". Прерываться "где-то внутри" (а, вернее, приостанавливаться) он может только в случае неудовлетворения условия в AWAIT. При этом активность, для которой не удовлетворилось данное условие помещается в очередь, ожидающих выполнения условий.

Re: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: LaptevVV rsdnhttp://vk.com/id59893040
Дата: 15.10.04 07:24
Здравствуйте, vladserge, Вы писали:

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


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



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

В Яве можно объявить метод sinchronized — имхо как раз то самое.
Наши программисты — самые программистые программисты в мире!
Re[3]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Сергей Губановhttp://moikrug.ru/users/P628059486/
Дата: 15.10.04 07:27
Здравствуйте, vladserge, Вы писали:

V>я утверждаю что все произойдет с точностью до НАОБОРОТ.

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

Вы совершенно правы. Операционная система Aos Bluebotle написанная на языке Active Oberon демонстрирует производительность превышающую производительность ОС Linux в несколько раз.

http://www.rsdn.ru/Forum/Message.aspx?mid=853268&only=1
Автор: Сергей Губанов
Дата: 15.10.04


Сама Aos:
http://bluebottle.ethz.ch/
Re[7]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Merle rsdnhttp://rsdn.ru
Дата: 15.10.04 08:06
Оценка:77 (6)
Здравствуйте, Кодт, Вы писали:

К>Дык, вроде бы все так и делают, кроме отморозков. Любая функция захвата ресурса с ненулевым таймаутом приводит к переключению. А заниматься, простите, онанизмом вида

К>
К>while(!take(semaphore, 0)) {}
К>

К>нафиг надо?
Ну я там не совсем верно объяснил... Проблема в том, что даже стандартный, на первый взгляд вполне безопасный подход, со спинлоками, способен привести к конвою.
Допустим есть ресурс, который захватывается и освобождается много раз в течении кванта потока.
Если переключение контекста произошло в тот момент, когда ресурс захвачен, другие потоки, бесполезно покрутившись на спинлоке, впадают в спячку, поставив себя в очередь. Если же переключение контекста произошло в тот момент, когда ресурс свободен, то ресурс оказывается немедленно захвачен другим потоком, а первоначальный поток, при попытке опять воспользоваться ресурсом, попадает на ожидание и оказывается в конце очереди. Со временем очередь только растет и конвой не рассасывается до возникновения какой-нибудь нерегулярности. И дальше по кругу — ни один поток не может удержать ресурс дольше небольшой доли кванта (квант / сколько раз за квант ресурс захватывается потоком).

Вот воркэраунд от MS по борьбе с конвоями:
// ACQUIRE 
//
retries = 0; 
while( !TryEnterCriticalSection(&CritSec) ){ 
  if( retries++ < 100 ){ 
    if( retries % 10 ){         // DelayBetweenReferences 
      for( i=0; i<Delay; i++);  // Delay = 1<<(cpus-1) 
    } else { 
      SwitchToThread();         //10 ctxsw max    
    } 
    continue; 
  } 
  EnterCriticalSection(&CritSec);    
  break; 
} 

// RELEASE 
//
LeaveCriticalSection(&CritSec);

В данном случае, нарвавшись на блокировку поток не ставит себя в очередь, а явно передает управление дальше по цепочке.
Как только исчезает очередь, конвой рассасывается, будет серия быстрых переключений контекста, нопосле освобождения ресурса никто его немедленно не захватывает, поэтому текущий поток спокойно может повторно им повладеть.
... [ RSDN@Home 1.1.4 revision 142 ]
Мы уже победили, просто это еще не так заметно...
Re: P. S. в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Сергей Губановhttp://moikrug.ru/users/P628059486/
Дата: 15.10.04 08:12
Здравствуйте, Merle, Вы писали:

M>Кстати, то, что ты называешь "атомарность", скорее стоит назвать "сериализуемость" или "изолированность"...


В Active Oberon это называется "эксклюзивность" {EXCLUSIVE}
Re[6]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Sinclair rsdnhttp://www.parallels.com/automation/operations/
Дата: 15.10.04 08:42
Здравствуйте, Merle, Вы писали:

M>Вообще классической по данному вопросу считается статья Дж. Грэя со товарищи, "The Convoy Phenomena", аж 79 года рождения (статья), но в открытом доступе мне ее, к сожалению, найти не удалось..

M>(Если интересно, можно Синклера потерзать, может быть у него остался аккаунт на http://portal.acm.org, там она есть)
Не, мне его закрыли за неуплату А по-новой я еще не собрался его переоткрыть
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Не волнуйтесь, всё чики-пуки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Сергей Губановhttp://moikrug.ru/users/P628059486/
Дата: 15.10.04 08:52
Здравствуйте, Сергей Губанов, Вы писали:

СГ>блок выполняется "целиком" и "сразу".



P. S.
Кстати, чтобы не загромождать текст программы словами EXCLUSIVE, некоторые операции гарантированно эксклюзивны. Например, операция n := n + 1; записанная как INC(n); является эксклюзивной, то есть вместо
некий код
...
BEGIN {EXCLUSIVE}
  n := n + delta
END
...
некий код

можно просто написать
некий код
...
INC(n, delta);
...
некий код

ну и т.п. для других элементарных операций...
Re[2]: P. S. в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Kluev 
Дата: 15.10.04 09:52
Оценка:1 (1)
Здравствуйте, vladserge, Вы писали:

Это будет очень хорошо работать в системах с одним процессором, где два треда просто не могут исполнятся одновременно, здесь действително будет очень круто не переключаемся пока не вышли из atomic. Однако в многопроцессорных системах будут траблы.
Re[3]: P. S. в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Сергей Губановhttp://moikrug.ru/users/P628059486/
Дата: 15.10.04 10:05
Оценка: :)
Здравствуйте, Kluev, Вы писали:

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


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


Эти траблы могут быть в не объектно ориентированных системах. В объектно ориентированных их не будет. Так, например, в Active Oberon таких траблов не возникает, поскольку секция EXCLUSIVE привязана к конкретной активности — активному объекту, остальные активности не имеющие к первой никакого отношения, разумеется, продолжают исполняться на других процессорах как ни в чем не бывало.
Re[4]: P. S. в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Kluev 
Дата: 15.10.04 10:30
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Kluev, Вы писали:


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


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


СГ>Эти траблы могут быть в не объектно ориентированных системах. В объектно ориентированных их не будет. Так, например, в Active Oberon таких траблов не возникает, поскольку секция EXCLUSIVE привязана к конкретной активности — активному объекту, остальные активности не имеющие к первой никакого отношения, разумеется, продолжают исполняться на других процессорах как ни в чем не бывало.


Это будет работать только если вы каждому акивному обьекту дадите по процессору. В противном случае траблы.
Re[5]: P. S. в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Nick_ 
Дата: 15.10.04 11:43
Здравствуйте, Kluev, Вы писали:

K>Это будет работать только если вы каждому акивному обьекту дадите по процессору. В противном случае траблы.


Что мешает это сделать?
Re[3]: P. S. в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: vladserge 
Дата: 15.10.04 12:14
Здравствуйте, Kluev, Вы писали:

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


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


К сожелению, ничего сколь нибудь компетентно на тему мультипроцессорности сказать не могу, нужно достаточно глубоко разбираться в этом. Однако основной смысл обсуждаемой модели в том что поток войдя в атомарную секцию обязан пройти её непереключаясь где либо в ней. Было бы интересно услышать мнение знатоков мульти процессорных вычислений какие возможны варианты прохождения такого кода. Как вообще ведут себя мультипроцессорные системы. Помимо рассуждений было бы очень полезно почитать что нибудь про это. Ссылочки толковые есть?
С Уважением Сергей Чикирев
Re[4]: P. S. в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Сергей Губановhttp://moikrug.ru/users/P628059486/
Дата: 15.10.04 12:54
Здравствуйте, vladserge, Вы писали:

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


О чем и речь. Ексклюзивная секция выпоняется целиком. И толковые ссылочки есть:

Вот пожалуйста, уже готовенькая операционка: http://bluebottle.ethz.ch/
А вот ее автор: http://www.cs.inf.ethz.ch/~muller/
А вот его докторская диссера посвященная этому вопросу: http://e-collection.ethbib.ethz.ch/cgi-bin/show.pl?type=diss&nr=14755
Re[5]: P. S. в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Сергей Губановhttp://moikrug.ru/users/P628059486/
Дата: 15.10.04 13:09
Здравствуйте, Kluev, Вы писали:

K>Это будет работать только если вы каждому акивному обьекту дадите по процессору. В противном случае траблы.


В каждый отдельно взятый момент времени, по настоящему "активны" лишь столько объектов, сколько есть в наличии процессоров. А остальные — ждут своего time slice. Так в чем, собственно, состоит Ваше утверждение? Если активных объектов будет больше чем процессоров, то будут траблы? По крайней мере Питеру Мюллеру, создателю Aos, предрекаемые Вами гипотетические траблы преодолеть как-то удалось.
Re[5]: P. S. в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: vladserge 
Дата: 16.10.04 04:39
Здравствуйте, Сергей Губанов, Вы писали:

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


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


СГ>О чем и речь. Ексклюзивная секция выпоняется целиком. И толковые ссылочки есть:


СГ>Вот пожалуйста, уже готовенькая операционка: http://bluebottle.ethz.ch/

СГ>А вот ее автор: http://www.cs.inf.ethz.ch/~muller/
СГ>А вот его докторская диссера посвященная этому вопросу: http://e-collection.ethbib.ethz.ch/cgi-bin/show.pl?type=diss&nr=14755

Спасибо
С Уважением Сергей Чикирев
Re[6]: P. S. в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Геннадий Васильевhttp://www.livejournal.com/users/gesha_x
Дата: 17.10.04 01:39
Здравствуйте, Сергей Губанов, Вы писали:

K>>Это будет работать только если вы каждому акивному обьекту дадите по процессору. В противном случае траблы.

СГ>В каждый отдельно взятый момент времени, по настоящему "активны" лишь столько объектов, сколько есть в наличии процессоров.

Это 100% коррелирует с моделью вытесняющей многозадачности в "обычной" операционной системе. Там тоже в один момент времени активно столько потоков, сколько имеется процессоров в компьютере. Остальные ждут timeslice.

СГ> А остальные — ждут своего time slice. Так в чем, собственно, состоит Ваше утверждение? Если активных объектов будет больше чем процессоров, то будут траблы? По крайней мере Питеру Мюллеру, создателю Aos, предрекаемые Вами гипотетические траблы преодолеть как-то удалось.


Никаких там чудес нет. Во всяком случае, если бы удалось, то в контексте Aos вообще не упоминалось бы понятий, связанных с синхронизацией. Как был фон-Нейман, так и остался. Как была необходимость разруливания потоков при обращении к ресурсам, так она и осталась.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Ну никаких тут чудес нет и быть не может в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Геннадий Васильевhttp://www.livejournal.com/users/gesha_x
Дата: 17.10.04 03:29
Оценка:3 (1) +1
Здравствуйте, vladserge, Вы писали:

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


Я перенёс цитаты из твоего диалога с Merle в этом же топике:

V>Я подразумеваю только то что подразумевает микрософт описывая Interlocked Class

V>

V>Provides atomic operations for variables that are shared by multiple threads.

V>и далее
V>

V>The Exchange method atomically exchanges the values of the specified variables. The CompareExchange method combines two operations: comparing two values and storing a third value in one of the variables, based on the outcome of the comparison. The compare and exchange operations are performed as an atomic operation.


Вот так бы сразу и сказал. Не забыл ещё, что он sealed?

Значит, давай начнём снизу, с процессора.

Есть у x86 такой префикс — lock. Префикс lock означает как раз требуемую тебе "атомарность":

(для 8086: )
На все время выполнения команды, снабженной таким префиксом, будет заблокирована шина данных, и если в системе присутствует другой процессор, он не сможет обращаться к памяти, пока не закончится выполнение команды с префиксом LOCK. Команда XCHG автоматически всегда выполняется с блокировкой доступа к памяти, даже если префикс LOCK не указан. Этот префикс можно использовать только с командами ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD и XCHG.

Цитата отсюда.

Дальше... учтём ещё пару интересных факторов.

Первый: оговорка в MSDN

The 64-bit versions of Increment and Decrement are truly atomic only on systems where a System.IntPtr is 64 bits long. On other systems, these methods are atomic with respect to each other, but not with respect to other means of accessing the data.


Второй: аргументы операций класса Interlocked сводятся к следующим:
— int* (адрес 32 битного значения);
— Object* (адрес размером 32/64 бита, в зависимости от архитектуры);
— int64* (адрес 64-битного целого, только Increment/Decrement и для систем с 64-битным адресом);
— Single/float (sizeof() == 4 байта!!!).

Притом, инкремента/декремента для float, естественно — нет.

Третий: сравним операции системы команд x86 и методы Interlocked:

Increment <-> inc
Decrement <-> dec
Exchange <-> xchg (кстати — всегда атомарна)
CompareExchange <-> cmpxchg, cmpxchg8b (для 8-байтовых)

Итак. Что получаем? А получаем то, что все методы Interlocked есть ни что иное, как обёртки над командами x86. Притом — каждый над своей. Отсюда становится понятно, почему атомарность обеспечивается только для операций над элементарными целыми типами и не обобщена на уровень произвольного куска кода. Также, становится понятна вышеупомянутая оговорка:

The 64-bit versions of Increment and Decrement are truly atomic only on systems where a System.IntPtr is 64 bits long. On other systems, these methods are atomic with respect to each other, but not with respect to other means of accessing the data.


Правильно, поскольку на системах, где арифметические операции с int64 эмулируются программно (а не реализованы аппаратурой), можно только равесить синхронизирующие примитивы в начале и конце Increment/Decrement. А этим можно добиться только того, что выполнение Interlocked.Increment (а равно и Interlocked.Decrement) в потоке A не пересечётся с выполнением такой же операции в потоке B ("these methods are atomic with respect to each other"). Однако, при этом шина обмена с памятью не блокируется процессором в течение всей операции. А значит — возможно переключение управления на планировщик со всеми вытекающими: "not with respect to other means of accessing the data". Т.е., операция м.б. прервана планировщиком, а данные потом модифицированы другим потоком.

Понятно также, почему нет аналогичной оговорки для Exchange/CompareExchange: спасают атомарные cmpxchg и cmpxchg8b.

<NB>
Тут, я полагаю, нужно учесть, что производители процессоров прекрасно осведомлены о том, что хоть для каких-то операций но необходимо уметь обеспечивать атомарность. Для Intel x86 есть префикс lock. Как для других процессоров — не знаю. Скорее всего, такая возможность есть всегда для операций обмена данными, размер которых совпадает с размером адреса. Нужно же как-то синхронизирующие примитивы реализовать для ОС!
</NB>

Скорее всего, что-то можно наиграть с командами 0-го кольца, но это уже за рамки полномочий .Net выходит. К счастью.

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


Это не в порядке наезда, но лучше всего почитай мануал по ассемблеру x86. Там ты найдёшь много интересного, а цитировать всё не хочется. Ключевые слова для поиска в сети: "LOCK x86", "memory barrier", "relaxed memory model", "flushing CPU cache".

Да, кстати. ИМХО, обеспечивать атомарность выполнения большого куска пользовательского кода для 3-го кольца защиты x86 — чистое самоубийство. А планирощик куда денем? Это — тоже программа. Процессор должен переключиться в её контекст... Прерывания опять таки кто-то обработать должен.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Ну никаких тут чудес нет и быть не может в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: vladserge 
Дата: 17.10.04 11:03
Здравствуйте, Геннадий Васильев, Вы писали:

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


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


ГВ>Я перенёс цитаты из твоего диалога с Merle в этом же топике:


V>>Я подразумеваю только то что подразумевает микрософт описывая Interlocked Class

V>>

V>>Provides atomic operations for variables that are shared by multiple threads.

V>>и далее
V>>

V>>The Exchange method atomically exchanges the values of the specified variables. The CompareExchange method combines two operations: comparing two values and storing a third value in one of the variables, based on the outcome of the comparison. The compare and exchange operations are performed as an atomic operation.


Вот Это ответ!!! Большое спасибо за развернутое, достаточно глубокое повествование по делу. Я только что у Рихтера прочитал то, о чем Вы тут написали. Очтается только колбасить что-то типа
if (Interlocked.CompareExchange(ref locked, 1, 0) == 0)
 {
  .......
  .......
  .......

   
  locked=0
 }


некрасиво, но нужную функциональность, экономичность, а главное высокую скорость имеем, для сервера это критически важно.

Еще раз спасибо.
С Уважением Сергей Чикирев
Re[2]: Ну никаких тут чудес нет и быть не может в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: VVB16 
Дата: 17.10.04 12:29
Оценка:1 (1)
Здравствуйте, vladserge, Вы писали:

V>Вот Это ответ!!! Большое спасибо за развернутое, достаточно глубокое повествование по делу. Я только что у Рихтера прочитал то, о чем Вы тут написали. Очтается только колбасить что-то типа

V>
V>if (Interlocked.CompareExchange(ref locked, 1, 0) == 0)
V> {
V>  .......
V>  .......
V>  .......

   
V>  locked=0
V> }
V>


...Только планировщику ничто не помешает переключить контекст при нахождении внутри if. Ну и вместо locked = 0 тоже надо Interlocked использовать. Фактически это try_lock у мутекса. Сдается мне, что critical section так и реализованы...

--
Vitaly Belekhov
Re[3]: Ну никаких тут чудес нет и быть не может в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: vladserge 
Дата: 17.10.04 12:42
Здравствуйте, VVB16, Вы писали:

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


V>>Вот Это ответ!!! Большое спасибо за развернутое, достаточно глубокое повествование по делу. Я только что у Рихтера прочитал то, о чем Вы тут написали. Очтается только колбасить что-то типа

V>>
V>>if (Interlocked.CompareExchange(ref locked, 1, 0) == 0)
V>> {
V>>  .......
V>>  .......
V>>  .......

   
V>>  locked=0
V>> }
V>>


VVB>...Только планировщику ничто не помешает переключить контекст при нахождении внутри if.


фиг с ним, я уже смирился,


VVB>... Ну и вместо locked = 0 тоже надо Interlocked использовать.


да, в примерах хелпов я обратил на это внимание , но немогу сообразить нафига это сделано так, ведь переменная обнуляется гарантированно только одним потоком который в секции, остальные её только "нюхают"
Нет ну правда ЗАЧЕМ?

VVB>.. Фактически это try_lock у мутекса. Сдается мне, что critical section так и реализованы...


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

VVB>--

VVB>Vitaly Belekhov
С Уважением Сергей Чикирев
Re[4]: Ну никаких тут чудес нет и быть не может в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: VVB16 
Дата: 18.10.04 06:35
Здравствуйте, vladserge, Вы писали:

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


VVB>>... Ну и вместо locked = 0 тоже надо Interlocked использовать.


V>да, в примерах хелпов я обратил на это внимание , но немогу сообразить нафига это сделано так, ведь переменная обнуляется гарантированно только одним потоком который в секции, остальные её только "нюхают"

V>Нет ну правда ЗАЧЕМ?

Чтобы она в кэше одного процессора не зависла с одним значением, а в памяти с другим при переключении потоков.
Т.е. может возникнуть ситуация, когда locked=0 в одном потоке прошел, а другой через interlocked все еще видит 1.

--
Vitaly Belekhov
Re[5]: Ну никаких тут чудес нет и быть не может в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: vladserge 
Дата: 18.10.04 09:17
Здравствуйте, VVB16, Вы писали:

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


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


VVB>>>... Ну и вместо locked = 0 тоже надо Interlocked использовать.


V>>да, в примерах хелпов я обратил на это внимание , но немогу сообразить нафига это сделано так, ведь переменная обнуляется гарантированно только одним потоком который в секции, остальные её только "нюхают"

V>>Нет ну правда ЗАЧЕМ?

VVB>Чтобы она в кэше одного процессора не зависла с одним значением, а в памяти с другим при переключении потоков.

VVB>Т.е. может возникнуть ситуация, когда locked=0 в одном потоке прошел, а другой через interlocked все еще видит 1.

да, не критически это,а если очень хочется для этого volatile есть .Так что вопрос остался
С Уважением Сергей Чикирев
Re: Чудеса есть в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Сергей Губановhttp://moikrug.ru/users/P628059486/
Дата: 18.10.04 10:15
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>...Есть у x86 такой префикс — lock....

ГВ>...оговорка в MSDN...

Ага, смотрим, раз упомянут MSDN значит речь идет о Винде и на 100% о языке Си/Си++; раз упомянут x86 значит идет привязка к конкретной аппаратной платформе. Отсюда, разумеется, следует, что "Ну никаких тут чудес нет и быть не может". А кто бы сомневался, что в Винде на Си/Си++ на x86 чудес нет!!!

Чудеса возникают только когда сам язык программирования предоставляет программисту высокоуровневые абстракции для работы с параллельными вычислениями. Натуральный способ добавить возможность параллельных вычислений в объектно ориентированный язык программирования — это ввести такую абстракцию как "активный объект" {ACTIVE}. Для того чтобы натуральным образом синхронизировать работу разных активностей, естественно ввести такую абстракцию как эксклюзивный блок кода {EXCLUSIVE} и явным образом ввести оператор ожидания {AWAIT}. Итого, надо добавить в язык всего три новых ключевых слова {ACTIVE, EXCLUSIVE, AWAIT}. Программу, написанную на таком языке программирования, потом можно портировать на машины с разными архитектурами. Даже на такие, где EXCLUSIVE очень даже будет или, наоборот, совсем не будет поддерживаться на аппаратном уровне, но программу это не касается т.к. это уже проблемы среды исполнения (runtime system).
...осталось свистнуть и принесть! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Геннадий Васильевhttp://www.livejournal.com/users/gesha_x
Дата: 19.10.04 01:15
Оценка:6 (1) +2 :)
Здравствуйте, Сергей Губанов, Вы писали:

ГВ>>...Есть у x86 такой префикс — lock....

ГВ>>...оговорка в MSDN...

СГ>Ага, смотрим, раз упомянут MSDN значит речь идет о Винде и на 100% о языке Си/Си++; раз упомянут x86 значит идет привязка к конкретной аппаратной платформе. Отсюда, разумеется, следует, что "Ну никаких тут чудес нет и быть не может".

Угу, поскольку не хочется переписывать планировщик, работающий, AFAIK, в 0-м кольце x86. Гораздо проще грамотно спланировать синхронизацию.

СГ> А кто бы сомневался, что в Винде на Си/Си++ на x86 чудес нет!!!

Это круто! Ты знаешь, вот как раз за это некоторые вроде меня C/C++ и любят. Никаких чудес! Всё, что нужно — сделаем сами.

СГ>Чудеса возникают только когда сам язык программирования предоставляет программисту высокоуровневые абстракции для работы с параллельными вычислениями. Натуральный способ добавить возможность параллельных вычислений в объектно ориентированный язык программирования — это ввести такую абстракцию как "активный объект" {ACTIVE}.

ИМХО, чудеса возникают там, где не хватает знаний и понимания реальности. Э... для наблюдателей, естественно. Для чудотворцев-то чудес никаких нет.

СГ>Для того чтобы натуральным образом синхронизировать работу разных активностей, естественно ввести такую абстракцию как эксклюзивный блок кода {EXCLUSIVE} и явным образом ввести оператор ожидания {AWAIT}.

ИМХО, ты заблуждаешься. Ничего тут естественного нет — в смысле, что язык необязательно модифицировать. Сам по себе EXLUSIVE — критическая секция и всё. Особенность — в планировщике задач Aos, который несколько необычно (не)переключает контексты — не только по таймеру, но и по другим событиям. И работает такой прикол (исключительное выполнение) только на однопроцессорных машинах, поскольку второй процессор в EXCLUSIVE-время тоже девать куда-то надо. Об этом и сами создатели пишут в техническом описании Aos. А если процессоров больше одного — то получаем банальную критическую секцию "в профиль".

Что касается AWAIT — то есть и conditional vars. А в винде есть Events. ИМХО — более чем смахивает на AWAIT.

Здесь преимущество Aos в относительной элегантности языковой конструкции, ну и всё. И больше ничего, вобщем-то.

СГ> Итого, надо добавить в язык всего три новых ключевых слова {ACTIVE, EXCLUSIVE, AWAIT}. Программу, написанную на таком языке программирования, потом можно портировать на машины с разными архитектурами. Даже на такие, где EXCLUSIVE очень даже будет или, наоборот, совсем не будет поддерживаться на аппаратном уровне, но программу это не касается т.к. это уже проблемы среды исполнения (runtime system).

Ну, это зависит от... ИМХО, для C++ более чем достаточно библиотечных примитивов. Условно, синтаксис может быть таким:

void method()
{
  EXCLUSIVE exc; // Должен влиять на планировщик.
    // Поехали!
    
    AWAIT(condition); // condition - адрес функции или замыкание или делегат
}


А дальше можно довернуть всё, что хочешь. ИМХО — на порядок гибче, чем введение в язык нового ключевого слова. Кстати, насколько я пока что понял — в Aos чекируются чуть ли не все вызова, а это скорости, ИМХО, добавлять не должно. Что, кстати, косвенно подтверждается их же тестами (посмотри в разделе 8.2, там есть не только сравнение длительности системного вызова).

Не, ты не подумай. Я против Aos ровным счётом ничего не имею — неплохая вполне разработка. Очень интересная, кстати. Но и делать из неё абсолютный пример для подражания, ИМХО — не верно. Одно только общее адресное пространство и единственный язык чего стоят! Та разница в длительности системных вызовов, о которой ты так часто вспоминаешь, на самом деле всего лишь следствие того, что Aos вертится в одном кольце защиты, а Linux — в четырёх. Т.е., немалая доля задержек обуславливается переключением колец защиты (а не только контекстов процессов). Если тебе хватит для синхронизации локальных блокировок (см. префикс LOCK), то можно выдавить максимальное быстродействие.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[4]: Ну никаких тут чудес нет и быть не может в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Геннадий Васильевhttp://www.livejournal.com/users/gesha_x
Дата: 19.10.04 02:05
Здравствуйте, vladserge, Вы писали:

VVB>>... Ну и вместо locked = 0 тоже надо Interlocked использовать.


V>да, в примерах хелпов я обратил на это внимание , но немогу сообразить нафига это сделано так, ведь переменная обнуляется гарантированно только одним потоком который в секции, остальные её только "нюхают"

V>Нет ну правда ЗАЧЕМ?

Некоторые машины могут футболить данные в память из кэша не в порядке обновления, а в порядке возрастания адресов (relaxed memory model). Для того, чтобы этого не случилось, используют барьеры памяти (memory barriers), которые гарантируют, что данные, модифицированные ранее инструкции барьера 100% попадут в основную память. А иначе ты можешь на многопроцессорной архитектуре получить, что значение locked=0 попадёт второму процессору раньше, чем результаты отработки того, что было между инструкциями:

if (Interlocked.CompareExchange(ref locked, 1, 0) == 0)


и

locked=0;


Т.е., на однопроцессорной машине не страшно, можно и так, как ты написал. На многопроцессорной может быть весьма опасным. Зависит от архитектуры. Кстати, вот цитата из MSDN-описания C-шной функции InterlockedIncrement:

On Itanium processor architectures, this function will generate a memory barrier (or fence) followed by the increment operation with acquire semantics. This ensures the strict memory access ordering that is necessary, but it can be slower than necessary. For performance-critical applications, you should consider using InterlockedIncrementAcquire or InterlockedIncrementRelease.


Вот тебе и ответ: вероятнее всего, методы Interlocked тоже тянут барьеры.

PS. Об этом явлении совсем немного есть у Александреску.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: Ну никаких тут чудес нет и быть не может в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: VVB16 
Дата: 19.10.04 05:58
Оценка:1 (1)
Здравствуйте, vladserge, Вы писали:

VVB>>Чтобы она в кэше одного процессора не зависла с одним значением, а в памяти с другим при переключении потоков.

VVB>>Т.е. может возникнуть ситуация, когда locked=0 в одном потоке прошел, а другой через interlocked все еще видит 1.

V>да, не критически это,а если очень хочется для этого volatile есть .Так что вопрос остался


Кратко: volatile не поможет, это для компилятора совет, а для процессора он ничего не значит.
Можешь поиском найти статьи про double-checked locking и про то, что он практически не реализуем без специальной
поддержки со стороны процессора (о чем хорошо знаю Java-developers, походившие с ним по граблям). Тут та же самая
причина.

--
Vitaly Belekhov
Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Геннадий Васильевhttp://www.livejournal.com/users/gesha_x
Дата: 19.10.04 18:22
Здравствуйте, GlebZ, Вы писали:

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



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

GZ>class B
GZ>{
GZ>...
GZ>A _a;
GZ>void aaa()
GZ>{
GZ>lock(_a) // Это - правильно.
GZ>{
GZ>.....
GZ>//Изменения с внешней стороны
GZ>....
GZ>}
GZ>}
GZ>...
GZ>}
GZ>


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


И никакой гарантии защиты от дедлоков. Почему? Потому что объект блокирует сам себя ( lock(this) ), а на самом деле блокировка должна выполняться извне объекта, в зависимости от способа его обработки.

GZ>Защита какой-то отдельной процедуры практически никогда не нужно, и самое главное вредно. У тебя нет никакой гарантии, что при дальнейшем развитии не будет написана другая процедура работающая с этими данными.


То же самое справедливо и для самозащиты объекта.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[8]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Геннадий Васильевhttp://www.livejournal.com/users/gesha_x
Дата: 19.10.04 18:27
Здравствуйте, Merle, Вы писали:

M>Допустим есть ресурс, который захватывается и освобождается много раз в течении кванта потока.

M>Если переключение контекста произошло в тот момент, когда ресурс захвачен, другие потоки, бесполезно покрутившись на спинлоке, впадают в спячку, поставив себя в очередь. Если же переключение контекста произошло в тот момент, когда ресурс свободен, то ресурс оказывается немедленно захвачен другим потоком, а первоначальный поток, при попытке опять воспользоваться ресурсом, попадает на ожидание и оказывается в конце очереди. Со временем очередь только растет и конвой не рассасывается до возникновения какой-нибудь нерегулярности. И дальше по кругу — ни один поток не может удержать ресурс дольше небольшой доли кванта (квант / сколько раз за квант ресурс захватывается потоком).

Угу. ИМХО, как раз поэтому лучше всего блокировать все необходимые ресурсы до начала операции с ними. Заодно и разруливание ошибок захвата упрощается.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Sinclair rsdnhttp://www.parallels.com/automation/operations/
Дата: 20.10.04 03:20
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>И никакой гарантии защиты от дедлоков. Почему? Потому что объект блокирует сам себя ( lock(this) ), а на самом деле блокировка должна выполняться извне объекта, в зависимости от способа его обработки.
Что-то я не понимаю, каким образом самоблокировка вызовет дедлоки. Особенно в противовес внешней блокировке. Нет никакой связи между глубиной вызова lock в стеке и вероятностью deadlock.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: GlebZ 
Дата: 20.10.04 07:21
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>И никакой гарантии защиты от дедлоков. Почему? Потому что объект блокирует сам себя ( lock(this) ), а на самом деле блокировка должна выполняться извне объекта, в зависимости от способа его обработки.


Объект синхронизации защищает только от чужих потоков. Для своего потока он только подсчитывает число входов и выходов. Таким образом, deadlock для одного потока не будет. Для остальных потоков, блокировка действительна и следует следить за атомарностью изменений в контексте первого в стеке lock. Собственно, это и есть основное предназначение синхронизации.

С уважением, Gleb.
Re[2]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Геннадий Васильевhttp://www.livejournal.com/users/gesha_x
Дата: 20.10.04 15:33
Здравствуйте, Sinclair, Вы писали:

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

ГВ>>И никакой гарантии защиты от дедлоков. Почему? Потому что объект блокирует сам себя ( lock(this) ), а на самом деле блокировка должна выполняться извне объекта, в зависимости от способа его обработки.
S>Что-то я не понимаю, каким образом самоблокировка вызовет дедлоки. Особенно в противовес внешней блокировке. Нет никакой связи между глубиной вызова lock в стеке и вероятностью deadlock.

class A
{
    public B b;
    public void m1()
    {
        lock(this)
        {
            b.m1();
        }
    }
    public void m2()
    {
        lock(this)
        {
          // что-то унутреннее
        }
    }
}

class B
{
    public A a;

    public void m1()
    {
        lock(this)
        {
          // что-то унутреннее
        }
    }
    public void m2()
    {
        lock(this){
            a.m2();
        }
    }
}

// инициализация
A my_a = new A();
B my_b = new B();
my_a.b = my_b;
my_b.a = my_a;

// теперь из разных потоков одновременно вызываем:
my_a.m1();
// и
my_b.m2();


Такую ситуацию попросту сложно ловить: вроде бы, все объекты "правильно" блокируют сами себя, но в сумме получается дедлок при перекрёстной связи. Почему? Потому что может сложиться ситуация, когда my_a будет заблокирован из A.m1(), а my_b — из B.m2(). При этом они не смогут продолжить вычисления: первый запнётся на вызове b.m1(), а второй — на a.m2(). А если это ещё и на большой глубине стека происходит, да при неявных зависимостях классов, то секс почти гарантирован.

ИМХО, правильное решение должно быть таким:
lock(my_a){
lock(my_b){
  my_a.m1();
}
}

// и другой поток:
lock(my_a){
lock(my_b){
  my_b.m2();
}
}

Обязательное условие: порядок захвата объектов должен быть одинаковым в обоих случаях!!!
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Геннадий Васильевhttp://www.livejournal.com/users/gesha_x
Дата: 20.10.04 15:33
Здравствуйте, GlebZ, Вы писали:

GZ>Объект синхронизации защищает только от чужих потоков. Для своего потока он только подсчитывает число входов и выходов. Таким образом, deadlock для одного потока не будет. Для остальных потоков, блокировка действительна и следует следить за атомарностью изменений в контексте первого в стеке lock. Собственно, это и есть основное предназначение синхронизации.


Проблема в том, что таких объектов может оказаться не один, и тут-то всё и начнётся. См. соседний пост.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Sinclair rsdnhttp://www.parallels.com/automation/operations/
Дата: 21.10.04 04:35
Здравствуйте, Геннадий Васильев, Вы писали:
S>>Что-то я не понимаю, каким образом самоблокировка вызовет дедлоки. Особенно в противовес внешней блокировке. Нет никакой связи между глубиной вызова lock в стеке и вероятностью deadlock.

ГВ>Такую ситуацию попросту сложно ловить: вроде бы, все объекты "правильно" блокируют сами себя, но в сумме получается дедлок при перекрёстной связи. Почему? Потому что может сложиться ситуация, когда my_a будет заблокирован из A.m1(), а my_b — из B.m2(). При этом они не смогут продолжить вычисления: первый запнётся на вызове b.m1(), а второй — на a.m2(). А если это ещё и на большой глубине стека происходит, да при неявных зависимостях классов, то секс почти гарантирован.


ГВ>Обязательное условие: порядок захвата объектов должен быть одинаковым в обоих случаях!!!

Я так и думал Ты почти прав. Но видишь ли, в чем дело — применение предлагаемой тобой техники гарантирует отсутствие дедлоков только в том случае, если а) программист вручную заблокирует все необходимые объекты и б) если он во всех местах это сделает правильно. Точно такой же дедлок можно получить и в таком случае:
lock(my_a){
lock(my_b){
  my_a.m1();
}
}

// и другой поток:
lock(my_b){
lock(my_a){
  my_b.m2();
}
}


Именно поэтому я и говорю, что вероятность дедлока никак не связана с расположением блокирующего кода. Преимущество в том, что если ты словил дедлок в самоблокирующемся коде, то его можно за нефиг делать разрулить. Например, так:
class B
{
    public void m2()
    {
       a.m2();
    }
}

Или так:
class B
{
    public void m2()
    {
        lock(a) {            
        lock(this)
            {
       a.m2();
            }
            }
    }
}
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: GlebZ 
Дата: 21.10.04 07:28
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>
ГВ>class A
ГВ>{
ГВ>    public B b;
ГВ>    public void m1()
ГВ>    {
ГВ>        lock(this)
ГВ>        {
ГВ>            b.m1();
ГВ>        }
ГВ>    }
ГВ>    public void m2()
ГВ>    {
ГВ>        lock(this)
ГВ>        {
ГВ>          // что-то унутреннее
ГВ>        }
ГВ>    }
ГВ>}

ГВ>class B
ГВ>{
ГВ>    public A a;

ГВ>    public void m1()
ГВ>    {
ГВ>        lock(this)
ГВ>        {
ГВ>          // что-то унутреннее
ГВ>        }
ГВ>    }
ГВ>    public void m2()
ГВ>    {
ГВ>        lock(this){
ГВ>            a.m2();
ГВ>        }
ГВ>    }
ГВ>}

ГВ>// инициализация
ГВ>A my_a = new A();
ГВ>B my_b = new B();
ГВ>my_a.b = my_b;
ГВ>my_b.a = my_a;

ГВ>// теперь из разных потоков одновременно вызываем:
ГВ>my_a.m1();
ГВ>// и
ГВ>my_b.m2();

ГВ>


Замечательная конструкция. Сразу хочется сказать несколько вещей:
1. Явная ошибка программиста введена сознательно? Если другой объект является расшаренным между несколькими объектами, то при выполнении нужно его синхронизировать. Согласись, это азы.
2. Отсутсвие deadlock никто никогда не гарантировал. Если есть 2 mutex, взаимная блокировка возможна, независимо от того как ты блокируешь (см. пример Sinclair). Вопрос, можно ли это контролировать.
3. Неконтролируемый вход DeadLock в данной ситуации невозможен. Оба объекта должны быть видны друг другу, и соответсвенно делались в одном и том же приложении. Соответсвенно, это контролируемая ситуация, и ты вряд ли сможешь попасть в deadlock с объектом, реализация которого тебе неизвестна.
4. При правильном теоретическом подходе, любую идею можно испортить.

С уважением, Gleb.
Re[3]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Кодт rsdn 
Дата: 21.10.04 07:40
Оценка:10 (2)
Здравствуйте, Геннадий Васильев, Вы писали:

GZ>>Объект синхронизации защищает только от чужих потоков. Для своего потока он только подсчитывает число входов и выходов. Таким образом, deadlock для одного потока не будет. Для остальных потоков, блокировка действительна и следует следить за атомарностью изменений в контексте первого в стеке lock. Собственно, это и есть основное предназначение синхронизации.


ГВ>Проблема в том, что таких объектов может оказаться не один, и тут-то всё и начнётся. См. соседний пост.


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

Впрочем, есть способы борьбы с таким явлением:
1) Конечные таймауты. Ждать не до посинения, а некоторое разумное время, после чего обламываться (и повторять попытку)
2) Построить граф блокировок. Он должен быть ациклическим. Это делается на стадии проектирования! Но и во время исполнения можно построить текущий граф и проверить его на циклы; если очередная блокировка создаёт цикл — это исключительная ситуация.
3) Есть 3 кондовых способа реализации ациклических графов:
3.1) Единственный синхрообъект
3.2) Потоку разрешается захват единственного синхрообъекта в каждый момент времени
3.3) Все синхрообъекты пронумерованы, и захватывать надо не только один, но и все предшествующие
Перекуём баги на фичи!
Re[4]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Merle rsdnhttp://rsdn.ru
Дата: 21.10.04 08:16
Оценка:2 (1)
Здравствуйте, Кодт, Вы писали:

К>2) Построить граф блокировок. Он должен быть ациклическим.

Угу, он же Wait-for Graph — граф ожидания.
Но тут встает вопрос, как часто проводить проверку на ацикличность графа? Слишком часто — будет накладно, слишком редко, долго разруливать конфликт... Зато при этом способе можно откатить не кого попало, а в соответствии с логикой приложения.

Есть еще один способ, на основе time-stamp'ов...

Каждой транзакции присваивается временная метка, а далее возможно два варианта развития событий в зависимости от конкретной реализации.

«ожидание-гибель» (wait-die). Если транзакция T1 «старше» Т2, тогда транзакции Т1 разрешается пребывать в состоянии ожидания на блокировке. Если же Т1 «младше» T2, тогда Т1 откатывается.
«ранение-ожидание» (wound-wait). Если транзакция T1 «старше» T2, тогда T1 «ранит» T2; ранение обычно носит «смертельный» характер – транзакция Т2 откатывается, если только к моменту получения «ранения» T2 не оказывается уже завершенной. В этом случае Т2 «выживает» и отката не происходит. Если же Т1 «младше» Т2, тогда Т1 разрешается находиться в состоянии ожидания на блокировке.
Преимущества этого способа заключаются в первую очередь в том, что взаимоблокировки не допускаются в принципе. Этот способ несколько проще в реализации, нежели построение и отслеживание графа ожидания. И, наконец, отсутствует вероятность циклического рестарта отмененной транзакции, так как при откате временная метка сохраняется, и любая транзакция со временем гарантировано станет самой «старшей», а значит, ее не откатят.

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

... [ RSDN@Home 1.1.4 revision 142 ]
Мы уже победили, просто это еще не так заметно...
Re[5]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: GlebZ 
Дата: 21.10.04 08:26
Здравствуйте, Merle, Вы писали:

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

С уважением, Gleb
Re[6]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Sinclair rsdnhttp://www.parallels.com/automation/operations/
Дата: 21.10.04 08:37
Здравствуйте, GlebZ, Вы писали:
GZ>Замечательная вещь, откаты в рантайме, на компиленном коде. Будем создавать паттерн Command везде где только можно?
А есть какие-то альтернативы? Не нравятся откаты — вообще избегайте блокировок. Пользуйтесь Гармонично Взаимодействующими Процессами (с) Дийкстра. Благо в винде, например, все для них уже сделано
Вообще, конечно, можно и без откатов. При детектировании дедлока можно просто выкидывать исключение из функции lock. Это по крайней мере лучше, чем просто ждать ресета.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Merle rsdnhttp://rsdn.ru
Дата: 21.10.04 08:37
Здравствуйте, GlebZ, Вы писали:

GZ>Замечательная вещь, откаты в рантайме, на компиленном коде. Будем создавать паттерн Command везде где только можно?

Это уже другой вопрос. Я в данном случае рассматриваю "сферического коня в вакуме", некоторая абстрактная задача по разруливанию дедлоков.
Я в полне допускаю, что в реальных приложениях любая из предложеных стратегий может оказаться наиболее оптимальной.
Не согласны?
... [ RSDN@Home 1.1.4 revision 142 ]
Мы уже победили, просто это еще не так заметно...
Re[4]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: GlebZ 
Дата: 21.10.04 08:42
Здравствуйте, Кодт, Вы писали:

Все прекрасно, если бы не практика.

К>Впрочем, есть способы борьбы с таким явлением:

К>1) Конечные таймауты. Ждать не до посинения, а некоторое разумное время, после чего обламываться (и повторять попытку)
Хорошая и правильная идея. Еще бы спецификация lock позволяла бы устанавливать TimeOut, после которого генерился бы Exception, было бы круто.
К>2) Построить граф блокировок. Он должен быть ациклическим. Это делается на стадии проектирования!
Согласен, абсолютно и полностью.
К>Но и во время исполнения можно построить текущий граф и проверить его на циклы; если очередная блокировка создаёт цикл — это исключительная ситуация.
Напишем RSDN SQL, и все в порядке. Сколько это решение стоить будет.
К>3) Есть 3 кондовых способа реализации ациклических графов:
К>3.1) Единственный синхрообъект
Недостаток вполне понятный, производительность. И иногда это невозможно.
К>3.2) Потоку разрешается захват единственного синхрообъекта в каждый момент времени
Недостаток, невозможно сделать атомарность изменений.
К>3.3) Все синхрообъекты пронумерованы, и захватывать надо не только один, но и все предшествующие
Недостаток в производительности. Но при определенных ситуациях и решениях, вполне сносный способ.
Из данного сообщения, я бы все таки выделил ваше предложение: Построить граф блокировок. Он должен быть ациклическим. Это делается на стадии проектирования.

С уваженим, Gleb.
Re[7]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: GlebZ 
Дата: 21.10.04 08:49
Здравствуйте, Sinclair, Вы писали:

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

GZ>>Замечательная вещь, откаты в рантайме, на компиленном коде. Будем создавать паттерн Command везде где только можно?
S>А есть какие-то альтернативы? Не нравятся откаты — вообще избегайте блокировок. Пользуйтесь Гармонично Взаимодействующими Процессами (с) Дийкстра. Благо в винде, например, все для них уже сделано
S>Вообще, конечно, можно и без откатов. При детектировании дедлока можно просто выкидывать исключение из функции lock. Это по крайней мере лучше, чем просто ждать ресета.
Второе утверждение мне больше нравится. В соседнем посте написал, к сожалению еще до того как получил до вашего сообщения.

С уважением, Gleb
Re[7]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: GlebZ 
Дата: 21.10.04 08:59
Здравствуйте, Merle, Вы писали:

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


GZ>>Замечательная вещь, откаты в рантайме, на компиленном коде. Будем создавать паттерн Command везде где только можно?

M>Это уже другой вопрос. Я в данном случае рассматриваю "сферического коня в вакуме", некоторая абстрактная задача по разруливанию дедлоков.
M>Я в полне допускаю, что в реальных приложениях любая из предложеных стратегий может оказаться наиболее оптимальной.
M>Не согласны?
Хотя в принципе, почему бы и нет? Нет решений которые невозможно применить, просто задачи где такое решение оптимально не часто на практике попадаются. Теоретически, даже на уровне компилированного кода, могу придумать много задач где данное решение будет эффективным.

С уважением, Gleb.
Re[5]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Кодт rsdn 
Дата: 21.10.04 09:21
Здравствуйте, Merle, Вы писали:

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


К>>2) Построить граф блокировок. Он должен быть ациклическим.

M>Угу, он же Wait-for Graph — граф ожидания.
M>Но тут встает вопрос, как часто проводить проверку на ацикличность графа? Слишком часто — будет накладно, слишком редко, долго разруливать конфликт... Зато при этом способе можно откатить не кого попало, а в соответствии с логикой приложения.

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

Все синхрообъекты делятся на 2 категории: мгновенные и тормозные.
Мгновенные — это мониторы доступа к разделяемым данным. Залез, ковырнул, вылез. На стадии проектирования (или отладки) избегаем взаимных блокировок, да и вообще длительного пребывания внутри.
А с тормозными — можно и проверять.

M>Есть еще один способ, на основе time-stamp'ов...


Для взаимодействия клиент-сервер вариант отлуп-повтор транзакции это обычное дело.
А вот внутри программы, пожалуй, любой отлуп — это исключительная ситуация. Плюс накладные расходы на откат транзакции.
Перекуём баги на фичи!
Re[6]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Merle rsdnhttp://rsdn.ru
Дата: 21.10.04 09:35
Здравствуйте, Кодт, Вы писали:

К>Проверять нужно всегда (то есть, каждая операция захвата вносит коррективы в граф ожидания), но не для всех объектов.

При достаточно большом графе это может быть очень дорогой операцией. AFAIK ни одна СУБД (это как раз тот класс приложений где оптимальная проверка на взаимоблокировки одна из критичных частей), с deadlock монитором на основе графа ожидания не проверяет граф при каждом изменении, только по таймауту.

К>Все синхрообъекты делятся на 2 категории: мгновенные и тормозные.

К>Мгновенные — это мониторы доступа к разделяемым данным. Залез, ковырнул, вылез. На стадии проектирования (или отладки) избегаем взаимных блокировок, да и вообще длительного пребывания внутри.
К>А с тормозными — можно и проверять.
Можно комбинировать несколько подходов, собственно в тех же СУБД так и поступают. Для "легких" объектов используют правило "не больше одной блокировки", а для "тяжелых" строится граф.

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

Угу, но ситуации могут быть разными...

Есть еще решения для частных случаев, например, если граф объектов нуждающихся в синхронизации сам по себе представляет DAG, то есть алгоритмы гарантирующие отсутствие дедлоков.
... [ RSDN@Home 1.1.4 revision 142 ]
Мы уже победили, просто это еще не так заметно...
Re[5]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Кодт rsdn 
Дата: 21.10.04 11:15
Здравствуйте, GlebZ, Вы писали:

К>>Но и во время исполнения можно построить текущий граф и проверить его на циклы; если очередная блокировка создаёт цикл — это исключительная ситуация.

GZ>Напишем RSDN SQL, и все в порядке. Сколько это решение стоить будет.

Я сталкивался с проблемой дедлоков в многопоточном приложении с запутанной архитектурой. Поскольку грамотно переосмыслить и перепроектировать тогда не удалось, сделал несложный механизм отслеживания циклов в реальном времени.
Строятся 2 таблицы — захвата ресурсов и ожидания потоков. Перед захватом мутекса выполняется проверка и модификация этих таблиц; после освобождения — снова модификация.
Для отладочных целей — вполне хватало, даже производительность не сильно падала.
Перекуём баги на фичи!
Re[6]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: GlebZ 
Дата: 21.10.04 12:18
Здравствуйте, Кодт, Вы писали:

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

К>Строятся 2 таблицы — захвата ресурсов и ожидания потоков. Перед захватом мутекса выполняется проверка и модификация этих таблиц; после освобождения — снова модификация.
К>Для отладочных целей — вполне хватало, даже производительность не сильно падала.

Спасибо за учение, приму к сведению что данный вариант реализуем. Если не секрет, чем циклы находили?

С уважением, Gleb.
Re[7]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Кодт rsdn 
Дата: 21.10.04 14:10
Оценка:21 (1)
Здравствуйте, GlebZ, Вы писали:

GZ>Спасибо за учение, приму к сведению что данный вариант реализуем. Если не секрет, чем циклы находили?


Руками, чем же ещё
// таблицы зависимостей
mutex waiting(thread); // кого ждёт данный поток
thread locked(mutex); // кто держит данного мутекса

bool check_deadlock(thread t, mutex m) // true если дедлок
{
  if(locked(m)==t) return false; // реентер - разрешён (для семафоров так делать нельзя, разумеется)

  while(true)
  {
    thread d = locked(m);
    if(!d) return false;
    if(d==t) return true;

    m = waiting(d);
    if(!m) return false;
  }
}
Перекуём баги на фичи!
Re[4]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Геннадий Васильевhttp://www.livejournal.com/users/gesha_x
Дата: 21.10.04 16:53
Здравствуйте, Кодт, Вы писали:

GZ>>>Объект синхронизации защищает только от чужих потоков. Для своего потока он только подсчитывает число входов и выходов. Таким образом, deadlock для одного потока не будет. Для остальных потоков, блокировка действительна и следует следить за атомарностью изменений в контексте первого в стеке lock. Собственно, это и есть основное предназначение синхронизации.

ГВ>>Проблема в том, что таких объектов может оказаться не один, и тут-то всё и начнётся. См. соседний пост.
К>Дедлок можно получить разными способами, не обязательно на мониторах.
К>Любое синхронизированное действие — например, чтение/запись файла, внешнего устройства — чревато взаимоблокировкой.

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

К>Впрочем, есть способы борьбы с таким явлением:

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

На мой взгляд, опасно излишне увлекаться самоблокировкой объектов, хотя в некоторых случаях это — вполне адекватное решение. Например — для синглтонов, которые управляют распределением памяти. Почему нет? Проблемы могут быть если: а) увлечься самоблокируемыми объектами и б) завязать их в кучу.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[4]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Геннадий Васильевhttp://www.livejournal.com/users/gesha_x
Дата: 21.10.04 16:53
Здравствуйте, Sinclair, Вы писали:

S>Именно поэтому я и говорю, что вероятность дедлока никак не связана с расположением блокирующего кода. Преимущество в том, что если ты словил дедлок в самоблокирующемся коде, то его можно за нефиг делать разрулить.


Этого можно было и не писать. Я противопоставил своё мнение выражению "сейчас модно...". Понятно, что всегда можно что-то скривить и как-то выпрямить.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[4]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Геннадий Васильевhttp://www.livejournal.com/users/gesha_x
Дата: 21.10.04 16:55
Здравствуйте, GlebZ, Вы писали:

GGZ>Замечательная конструкция. Сразу хочется сказать несколько вещей:

GZ>1. Явная ошибка программиста введена сознательно? Если другой объект является расшаренным между несколькими объектами, то при выполнении нужно его синхронизировать. Согласись, это азы.
Соглашусь. Но это может быть труднопонимаемыми азами, если увлечься модой.

GZ>2. Отсутсвие deadlock никто никогда не гарантировал. Если есть 2 mutex, взаимная блокировка возможна, независимо от того как ты блокируешь (см. пример Sinclair). Вопрос, можно ли это контролировать.

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

GZ>3. Неконтролируемый вход DeadLock в данной ситуации невозможен. Оба объекта должны быть видны друг другу, и соответсвенно делались в одном и том же приложении.

С этим можно поспорить, поскольку например A может быть на самом деле унаследован от какого-то несамоблокируемого Z, который реализован вместе с B. Впрочем — так фантазировать можно долго.

GZ> Соответсвенно, это контролируемая ситуация, и ты вряд ли сможешь попасть в deadlock с объектом, реализация которого тебе неизвестна.

Ну... если мне неизвестна реализация объекта, то мне ничего неизвестно о нём кроме соглашений об интерфейсах.

GZ>4. При правильном теоретическом подходе, любую идею можно испортить.

Э... Ура!
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: GlebZ 
Дата: 22.10.04 09:23
Здравствуйте, Геннадий Васильев, Вы писали:

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


ГВ>Зависит от дизайна и трезвомыслия дизайнера. Потому я и не люблю выражение "модно" по отношению к реализации технических устройств.

см снизу

ГВ>Ну... если мне неизвестна реализация объекта, то мне ничего неизвестно о нём кроме соглашений об интерфейсах.

Почему я написал именно "модно". Дело в том, что у меня нет информации из доверяемых мною источников, что не произойдет некотнролируемый deadlock (или не произойдет). Что подразумевается под термином неконтролируемый deadlock: неконтролируемый deadlock — deadlock который нельзя выявить организационными или другими (как показал Koдт) мерами. То есть, если ты обладаешь только интерфейсом (имеется в виду интерфейс класса) некоторого instance написанного внешним разработчиком, можешь ли ты его блокировать не попадая в ситуацию deadlock.
Поскольку у меня нет сведений в обратном, я использую данный метод, благо он действительно удобен в вышеописанной ситуации. Именно поэтому, я скептически указал именно "модно". Должен, правда, покаятся, что данные источники не искал (как то всегда существуют более насущные проблемы). Вышеописанные вами ситуации, с помощью организационных мер, вполне разрешимы.

С уважением, Gleb.
Re[6]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Геннадий Васильевhttp://www.livejournal.com/users/gesha_x
Дата: 22.10.04 14:01
Здравствуйте, GlebZ, Вы писали:

ГВ>>Ну... если мне неизвестна реализация объекта, то мне ничего неизвестно о нём кроме соглашений об интерфейсах.

GZ>Почему я написал именно "модно". Дело в том, что у меня нет информации из доверяемых мною источников, что не произойдет некотнролируемый deadlock (или не произойдет). Что подразумевается под термином неконтролируемый deadlock: неконтролируемый deadlock — deadlock который нельзя выявить организационными или другими (как показал Koдт) мерами. То есть, если ты обладаешь только интерфейсом (имеется в виду интерфейс класса) некоторого instance написанного внешним разработчиком, можешь ли ты его блокировать не попадая в ситуацию deadlock.
GZ>Поскольку у меня нет сведений в обратном, я использую данный метод, благо он действительно удобен в вышеописанной ситуации. Именно поэтому, я скептически указал именно "модно". Должен, правда, покаятся, что данные источники не искал (как то всегда существуют более насущные проблемы). Вышеописанные вами ситуации, с помощью организационных мер, вполне разрешимы.

Хмм... ну, я не совсем понял, о чём здесь идёт речь. Извини пожалуйста, или переформулируй. Вобщем, если ты уверен в своих действиях — не вижу проблемы.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: 0xDEADBEEF 
Дата: 09.11.04 15:29
Оценка: +1
Здравствуйте, vladserge, Вы писали:

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


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


...то есть, заставить планировщика не переключать потоки до тех пор пока, блок не выполнится?
Типа старого доброго CLI/STI под Досом?

Не получится. И смотри почему.
— это полностью разрушит preemptive multitasking. Предположим ты засунул с "atom"-блок всю свою программу.
— что делать планировщику на многопроцессорных машинах? Морозить все потоки что выполняются на других процессорах пока твой любимый атомарный блок не соизволит кончиться?
__________
16.There is no cause so right that one cannot find a fool following it.
Re[2]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Сергей Губановhttp://moikrug.ru/users/P628059486/
Дата: 10.11.04 09:03
Оценка: -1
Здравствуйте, 0xDEADBEEF, Вы писали:

DEA> Не получится.


Получится. Уже реализовано: http://www.rsdn.ru/Forum/Message.aspx?mid=851366&only=1
Автор: Сергей Губанов
Дата: 14.10.04
Re[3]: Атомарность в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Sinclair rsdnhttp://www.parallels.com/automation/operations/
Дата: 10.11.04 09:36
Оценка: +2
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Получится. Уже реализовано: http://www.rsdn.ru/Forum/Message.aspx?mid=851366&only=1
Автор: Сергей Губанов
Дата: 14.10.04

Не надо ля-ля уже. Перечитай исходный постинг, и сравни со своим. Либо ты не понимаешь, чем отличается "недопуская переключения потока" от "до того как кто-то другой захочет выполнить это же самое действие", то тебе категорически противопоказано заниматься программированием.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: stalcer 
Дата: 01.04.05 12:20
Здравствуйте, Sinclair, Вы писали:

S>Пользуйтесь Гармонично Взаимодействующими Процессами (с) Дийкстра.


Че-то не гуглится .
Re[8]: Дедлоки! в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: GlebZ 
Дата: 01.04.05 17:15
Здравствуйте, stalcer, Вы писали:

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


S>>Пользуйтесь Гармонично Взаимодействующими Процессами (с) Дийкстра.


S>Че-то не гуглится .


Dijkstra, "Cooperating sequential processes"

С уважением, Gleb.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>