datalink

— Проблемы с именованием, используете C++, stl, так и именуйте в стиле stl, давайте методам осмысленные имена.
— Не забывайте о typedef для value_type и подобных
— Зачем тип вершины заворачивать в shared_ptr? Это приведет к оверхеду, это приведет к снижению производительности
— vertices.at(x); используется совсем не по назначению, если надо кинуть out_of_range, так и проверяйте с размером и кидайте руками.
— Как написано выше operator<< выводить должен в stream, а не std::cout
— Vertice* vertice(int index) const необходимо возвращать ссылку, либо кидать исключение out_of_range, а не указатель.

Кроме озвученного выше, еще добавлю
— Из конструктора можете смело выкидывать capacity.
— Переменные классы лучше именовать так, чтоб отличались от локальных — mVertices, vertices_, _vertices… whatever.
— Vertice* vertice(int index) const — это плохой метод. Константный метод, возвращающий неконстантный указатель — это явно что-то не то. Думаю, вам нужно возвращать значение, либо константную ссылку.

1. Строка 43: вы возвращаете «сырой» указатель, а не shared pointer — так и задумано?

2. Общее замечание: в единственном числе «вершина» будет «vertex».

3. Не реализован метод удаления вершины.

Давно с C++ дел не имел, но вроде у вас перегруженный оператор вывода в поток с ошибкой. Он всегда выводит в cout, даже если левый опреанд будет файлом или еще каким потоком.

Никогда не используйте CreateThread в C/C++ приложениях, используйте _beginthreadex. Об этом написано в каждом учебнике по WinAPI и в самой MSDN. Это сразу не понравится ревьюверу.
Конечно, можно в комментариях обосновать, что CreateThread использован специально, что в потоковой функции не используются вызовы CRT, но все равно, смысла в этом мало, потоковая функция может в будущем измениться.

Есть недочеты как в части знания и применения идиом C++, так и в скиле системного программирования.

Базовый класс InterthreadObject — фе. В данном случае правильно использовать агрегацию. Вместо Enter/LeaveCriticalSection использовать класс lock a-la boost scoped_lock. Что на счет копирования/присваивания таких объектов?

StopperCondition — а зачем там вобще синхронизация? (Здесь соискатель может начинать рассказывать про volatile, барьеры и тд).

InterthreadRequestQueue перевести на умные указатели или обосновать почему они здесь не нужны. Не использовать new[] для выделения буфера под хэндлы. Сами хэндлы сделать объектом для автоматического закрытия в деструкторе.

Возможно им не понравился printf. Лично у меня вызывает неприятие getc(cin) в конце main. Возможно, ожидается обработка исключений раз уж GetRequest/StopRequest старательно объявлены как no-throw.

Consumer thread будет находиться в состоянии активного ожидания при исчерпании очереди. Более того несколько консъюмеров будут мешать друг другу и продьюсеру постоянно борясь за одну критическую секцию. Я бы оснастил очередь condition variable, это бы решило данную проблему.

Первое, что бросилось в глаза — банальная ошибка копипасты:

hSomeConsumerThread = CreateThread( NULL, 0, consumerThread, &s, 0, NULL);
if (NULL == hProducerThread)
{