Как вариант сделать массив из n деревьев, каждое со своим rwlock-ом. То есть при запроси put считаем индекс в этом от ключа массиве, лочим на запись все дерево, записываем элемент, олочиваем. А при чтении сответственно лочим на чтение. уменьшение столкновений в n-раз практически.
А как память считать можно обертку тупо написать вокруг malloc и free, ну или как там оно в паскале называется. И в некоторый счетчик добавлять/вычитать чиселки через mutex, конечно. И в некоторых точках его выводить. Это самый простой вариант.
А при чем тут md5? Чтоб считать индекс от строки? Можно взять проще, да хоть тупо остаток от деления суммы всех символов в ключе на размер таблицы. А в дереве вы сравниваете строки просто или как? Ну можно сделать на 10М и на 20М таблицу — разницы нет, такого размера, чтобы коллизий не было. А при добавлении/удаленнии в дерево, разве не происходит его перебалансировки?
И еще как вариант не изобретать своего протокола, а взять HTTP или добавить его поддержку. Если считывание и запись в сокеты происходит в отдельных потоках, зачем тогда неблокирующие? Или у вас там очереди на отправку, примем и обработку в каждом потоке и при неудачном чтении/записи происходит переход к poll-у?
А почему не просто хэшом, а деревом? Создать, например, таблицу на 4М и более элементов. В большинстве случаев будет работать значительно быстрее чем дерево. Когда элементов будет меньше чем в хэш-таблице и при относительно равном распределении ключей, вставка и выборка будет происходить за O(1) а не за O(log(n)). Как способ для блокировок, можно все пространство ключей разбить на n частей и лочить только соответствующую часть, а не все.
Вроде в валгринде есть такая штука как отслеживание гонок и дедлоков, но мне как то не приходилось с его помощью этим заниматься. А вообще, конечно, нужно изначально это планировать параллельность.
Это, кстати интересный вариант. Никогда почему то не додумывался использовать сигналы в С, только обработку некоторых типа SIGTERM, делал корректной. Выходит почти как исключения в C++.
Вообще ВСЕГДА нужно проверять, что возвращаяет malloc, но его тут нет. А использовать exit как в случае про xmalloc, как мне кажется странно. А если нужно завершить соединения, сделать shutdown сокетам, записать в файл, что еще не записал и тд. В более-менее сложной программе нельзя использовать exit.
Общего да. А на самом деле их много как раз для переименовывания. То есть внешне выглядит работа с регистром eax, например. А на самом деле это будет с каким-нить R12 или как он там внутренне называется.
Вообще 2 кратного роста потребления памяти я не замечал. Довольно странно. Указатели все таки это не весь код. Возможно в апаче используется много типов вроде size_t. Кроме возможности адресовать больше памяти, вообще должны быстрее выполняться 64х битные операции, тк код компилятор будет генерить зная о 64х битных регистрах. Регистров стало около 100 штук, что позволяет процессору генерить более эффективое внеочередное выполнение команд, тк возможностей переименовывания регистров больше. Думаю так же всегда происходит компиляция с поддержкой SEE. Короче плюсов масса. Из реально наблюдаемых стал значительно шустрее работать mysql. Сравнением выполнения своих программ я не занимался, но по памяти не сильная разница, думаю 30% верхних предел. Возможно в программах где кучи указателей и кода и мало данных разница будет больше. Плюсов на самом деле больше. Это только то что я вспомнил.
Удачи в суде! Нужно остаивать свою правоту! Еслиб они вернули деньги без разговоров в итоге покупатель был бы доволен, что не вина магазина в левом телефоне и магазин повел сбея правильно и вполне возможно следующий раз бы покупал в этом же магазе. По крайней мере не былоб этого поста, который отпугнет много потенциальных клиентов. Меня, например.
char const msg[] = «Hello World!\n»;
…
char const * end = begin + sizeof(msg)-1;
Таким образом не нужно будет вызывать strlen, и длина строки будет посчитана на этапе компиляции.