Привет Всем,

Только недавно взялся за многопоточное программирование, и вот такой пример использования InterlockedCompareExchange у меня не работает:

// есть mAddBusy - volatile bool член класса, инициализируется конструктором в false

printf( "mAddBusy = %d\n", mAddBusy );
long result = InterlockedCompareExchange( (volatile long*)&mAddBusy, true, false );
printf( "mAddBusy=%d result=%d\n", mAddBusy, result );

Если mAddBusy равно false, значит interlocked должен вернуть 0, а mAddBusy должно стать true.

А выводит:

mAddBusy = 0
mAddBusy=0 result=16777216

Уже пару часов ковыряю и не пойму в чём дело. Кто нибудь сталкивался с подобным?

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

S>mAddBusy = 0
S>mAddBusy=0 result=16777216

так будет лучше гораздо:
S>printf( "mAddBusy = %d\n", *(long*)&mAddBusy );

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

S>long result = InterlockedCompareExchange( (volatile long*)&mAddBusy, true, false );

Я бы добавил вместо этого volatile в само объявление переменной. А то мало ли как сэкономил компилятор на сохранениях.

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

N>Я бы добавил вместо этого volatile в само объявление переменной. А то мало ли как сэкономил компилятор на сохранениях.

ЧОРТ! Заработало! Вот уж не думал что компилер что-то химичит с bool. Спасибо огромное

Кто не понял, в примере mAddBusy надо сделать с типом volatile long, как и требует функция.

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

S>mAddBusy=0 result=16777216

16777216 = 0x01000000

выделенное это твой bool.
остальное попорченная память и ошибка форматирования

S>printf( "mAddBusy = %d\n", mAddBusy ); //взглянул на ногу — вроде в порядке
S>long result = InterlockedCompareExchange( (volatile long*)&mAddBusy, true, false ); //навел маузер на коленную чашечку и БАБАХ
S>printf( "mAddBusy=%d result=%d\n", mAddBusy, result ); //о ужас , а почему у меня теперь вместо ноги ЭТО?

Здравствуйте, Syberia, Вы писали:
S>Уже пару часов ковыряю и не пойму в чём дело. Кто нибудь сталкивался с подобным?

Про глупые ошибки тебе уже ответили. Но у нас же не форум по WinAPI, а по плюсам как-никак?

#include <atomic>
#include <iostream>

int main()
{
    std::atomic<bool> value = false;
    bool expected = false;

    std::cout << value << std::endl;
    value.compare_exchange_strong(expected, true);
    std::cout << value << std::endl;
}

AD>#include <atomic>
Спасибо, почитаю что это.

Будете смеяться, я в программировании много лет, и всё на плюсах, но был уверен что bool это int, и следовательно эквивалент long (как в Win API). У меня перерыв был 5 лет, видимо память сыграла шутку. Извините за глупый вопрос.

Кстати, удивительное на заметку, как программист я стал даже лучше — лишнее отсеялось. Впрягся почти сразу, все знания, за исключением этого курьёза на месте. Так что не бойтесь попробовать себя где-то ещё! (на этот оффтоп конечно лучше здесь не отвечать)

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

S>Будете смеяться, я в программировании много лет, и всё на плюсах, но был уверен что bool это int, и следовательно эквивалент long (как в Win API). У меня перерыв был 5 лет, видимо память сыграла шутку.

BOOL из Win API это действительно int (или unsigned int, не помню)

1/10/2014 1:17 PM, Pavel Dvorkin пишет:

> BOOL из Win API это действительно int (или unsigned int, не помню)
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx

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

S>Будете смеяться, я в программировании много лет, и всё на плюсах, но был уверен что bool это int, и следовательно эквивалент long (как в Win API).

На этом месте нужно остановиться и заглянуть
— в стандарт
— в спецификации компиляторов под разные ОС
Потому что иначе переход на 64 бита принесёт очень, очень много боли.

Основное правило:
1 == sizeof(bool) == sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long)
и ещё где-то рядом (между int и long long) болтается sizeof(intptr_t) == sizeof(void*).

1/10/2014 2:44 PM, Кодт пишет:

> Потому что иначе переход на 64 бита принесёт очень, очень много боли.
И без перехода принесет того же не меньше.
И вообще не понимаю, что за проблемам с этими 64?
Просто надо сразу писать код корректно и не завязываться на размеры
регистров, адресации. Просто забыть их размерности (ну может кроме char
— с этим сложнее, бывает что большие начальники упираются против юникода
руками и ногами).

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

К>Основное правило:
К>1 == sizeof(bool) == sizeof(char)

Хм, а это откуда?
Я помню обратил внимание на то, что в TC++PL не было ничего про равенство sizeof(bool) == 1, хотя подобная табличка там есть. Я даже занимался сознательной экономией на эту тему.

Вот например n3485.pdf:

5.3.3 Sizeof
1. ... [ Note: in particular, sizeof(bool), sizeof(char16_t), sizeof(char32_t), and sizeof(wchar_t) are implementation-defined.74 —end note ]
...
74) sizeof(bool) is not required to be 1.

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

К>Основное правило:
К>1 == sizeof(bool)

Это ещё с чего?
Стандарты C++ — нет такого требования, и есть явное разрешение, что оно не 1.
Стандарты C (смотрю для надёжности в C99) — нет такого.

К>- в стандарт

вот, заглянул.

К>- в спецификации компиляторов под разные ОС

А это уже местная зависимость.

К>Потому что иначе переход на 64 бита принесёт очень, очень много боли.

Может, он уже на 64. При чём тут переход?

К> == sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long)
К>и ещё где-то рядом (между int и long long) болтается sizeof(intptr_t) == sizeof(void*).

Вообще-то в последнем '>=', а не '=='.

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

N>Вообще-то в последнем '>=', а не '=='.

ставь мне заслуженный минус

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

>> Потому что иначе переход на 64 бита принесёт очень, очень много боли.
V>И без перехода принесет того же не меньше.
V>И вообще не понимаю, что за проблемам с этими 64?

Люди 15 лет писали под конкретный размер, решив, что это навечно.

V>Просто надо сразу писать код корректно и не завязываться на размеры
V>регистров, адресации.

Unix мир проходил этот переход на 5-10 лет раньше, чем Windows. Были не меньшие грабли, хотя, по моему мнению и мнению многих других, решены значительно корректнее. Совсем от завязки под конкретный размер, увы, не избавиться.
Тот же (u)intptr_t был придуман как средство решения проблем размерности уже на основании попыток перехода, до того не было адекватного аналога.

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

При чём тут большие начальники? Я вот сейчас медленно пытаюсь перетащить на python3 большой проект — граблей ой дохрена...

1/10/2014 5:55 PM, netch80 пишет:

> Люди 15 лет писали под конкретный размер, решив, что это навечно.
Я еще помню переход с 16 на 32. И тогда я уже уяснил, что на конкретные
размеры категорически нельзя ориентироваться, даже не помню их особо.
Чтобы узнать точно, какой точно у меня сейчас обычно в инет лезу читать.
Размеры по сути важны, если что-то куда-то передать надо или запаковать
как-то хитро или какой-то уж очень быстрый целочисленный код надо писать
и такое необходимо отделять от основного кода в модули. Все. Но все это
достаточно редкие задачи.

> Совсем от завязки под конкретный размер, увы, не
> избавиться.
Такие места должны быть не размазаны по коду, а локализованы.

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

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

V>Просто надо сразу писать код корректно и не завязываться на размеры
V>регистров, адресации.

А вдруг таки битиков в числе не хватит по задачу, например?..

1/10/2014 7:03 PM, Erop пишет:

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

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

E>А вдруг таки битиков в числе не хватит по задачу, например?..

Я в таких случаях использую boost::uint_t<bits>::fast/least/exact и т.п.