УСТРОЙСТВО И СПОСОБ ПРОГОНА МНОЖЕСТВА ПОТОКОВ Российский патент 2019 года по МПК G06F7/00 

Область техники, к которой относится изобретение

Настоящее изобретение относится к устройству и способу прогона множества потоков. В частности, устройство и способ настоящего изобретения позволяют посылать в определенном порядке запросы удаленного вызова процедуры (RPC) в пакете RPC для повышения эффективности процедуры RPC.

Уровень техники

RPC является механизмом, позволяющим выполнение функции в адресном пространстве другого процесса, который может быть другим компьютером. В типичной процедуре RPC запрос RPC формируется клиентом и затем посылается на сервер. Ответ RPC, который является ответом на запрос RPC, принимается клиентом от сервера.

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

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

Раскрытие изобретения

С точки зрения описанных выше проблем, особенно проблемы низкой эффективности выполнения процедуры RPC на стороне клиента, настоящее изобретение направлено на совершенствование состояния уровня техники. Поэтому настоящее изобретение имеет своей задачей обеспечение устройства и способа прогона множества потоков для повышения эффективности процедуры RPC.

Упомянутая выше задача настоящего изобретения достигается решением, предусмотренным в содержащихся здесь независимых пунктах формулы изобретения. Предпочтительные реализации настоящего изобретения дополнительно определяются в соответствующих зависимых пунктах формулы изобретения.

Первый вариант настоящего изобретения обеспечивает устройство прогона множества потоков. Устройство содержит память, клиента и менеджера RPC. Клиент выполнен с возможностью формирования для каждого из множества потоков запроса RPC на выполнение операции и сохранения сформированных запросов RPC (в базе данных) в памяти. Менеджер RPC выполнен с возможностью упорядочивания сохраненных запросов RPC. Клиент дополнительно выполнен с возможностью посылки упорядоченных запросов RPC в пакете RPC.

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

Кроме того, многочисленные запросы RPC упорядочиваются менеджером RPC. Пакет RPC, посланный клиентом, содержит упорядоченные запросы RPC. Следовательно, в пакете RPC существует порядок (последовательность) запросов RPC. Этот порядок указывает порядок выполнения RPC в приемнике пакета RPC, например, на сервере. Другими словами, пакет RPC определяет порядок выполнения RPC. Этот порядок определяет порядок выполнения каждого запроса RPC, содержащегося в пакете.

Как вариант, ответы, соответствующие запросам RPC, также пакетируются и посылаются в пределах единого ответа на пакет RPC, содержащий запросы RPC. Таким образом, объем служебной сигнализации связи снижается и эффективность устройства повышается.

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

Поэтому порядок запросов RPC создается, основываясь на порядке формирования запросов RPC. Чем раньше формируется запрос RPC, тем выше вероятность, что запрос RPC будет послан раньше по порядку. Например, первый запрос RPC формируется раньше, чем второй запрос RPC. В одном пакете RPC первый запрос RPC устанавливается по порядку с более высоким приоритетом, чем второй запрос RPC. Таким образом, ответ на первый запрос RPC, как ожидается, должен прибыть к клиенту раньше, чем ответ на второй запрос RPC. В соответствии с другим примером, третий запрос RPC имеет более высокий шанс быть посланным в более позднем пакете RPC, если третий запрос RPC сформирован позже, чем второй запрос RPC.

Во второй форме реализации устройства, соответствующего первой форме реализации первого варианта, менеджер RPC выполнен с возможностью определения для каждого из хранящихся запросов RPC по меньшей мере одного объекта и порядок хранения запросов RPC основывается на времени и определенном объекте.

Таким образом, при определении порядка запросов RPC менеджер RPC учитывает два параметра. Первый параметр - время, когда был сформирован запрос RPC. Второй параметр - объект, связанный с RPC. При рассмотрении различных параметров определение порядка запросов RPC становится более гибким. Объект может быть данными, содержащими запрос RPC, или ссылкой на некоторый тип ключа в запросе RPC. Такой объект может быть, например, объектом базы данных или данными, на основе которых выполняется операция. Операция может быть одной из следующих: добавление объекта, удаление объекта, модификация полей объекта, применение математических действий к полю объекта, восстановление некоторых частей объекта, преобразование объекта в другую схему.

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

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

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

Это облегчает передачу многочисленных запросов RPC, соответствующих одному объекту, через один пакет RPC. Например, второй запрос RPC формируется после первого запроса RPC и перед третьим запросом RPC. Полагая, что первый запрос RPC и третий запрос RPC соответствуют первому объекту, а второй запрос RPC соответствует второму объекту, третьему запросу RPC будет упорядочиваться так, чтобы иметь приоритет выше, чем второй запрос RPC.

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

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

В шестой форме реализации устройства, соответствующего пятой форме реализации первого варианта, состояние каждого сформированного запроса RPC является одним из следующих: PENDING (ожидание), SENDABLE (пригодное для посылки), SENT (послано) и COMPLETED (выполнено). Состояние устанавливается как PENDING в момент, когда сформированный запрос RPC сохранен в структуре данных. Состояние устанавливается как SENDABLE, если упорядоченный запрос RPC, соответствующий объекту, не послан и состояния всех предшествующих посланных запросов RPC, соответствующих упомянутому объекту, установлены как COMPLETED. Состояние устанавливается как SENT, если упорядоченный запрос RPC послан и ответ на упомянутый упорядоченный запрос RPC не получен клиентом. Состояние устанавливается как COMPLETED, если ответ на упорядоченный запрос RPC получен.

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

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

Другими словами, любой поток, проходящий в устройстве, может быть использован для посылки пакета, содержащего упорядоченные запросы RPC. Поток может быть одним и тем же или отличающимся от любого из множества потоков, формирующих запросы RPC. Следовательно, устройство не должно иметь специального потока, выделенного для посылки пакетов, что приводит к более эффективному использованию процессора (например, центрального процессора, CPU).

В восьмой форме реализации устройства, соответствующего седьмой форме реализации первого варианта, упорядоченные запросы RPC посылаются серверу, находящемуся вне устройства, например, в другом компьютерном устройстве.

Следовательно, эффективность передачи запросов RPC между двумя устройствами, которые могут быть расположены на удалении друг от друга (два компьютера), повышается.

В девятой форме реализации устройства, соответствующего любой из предыдущих форм реализации первого варианта, клиент выполнен с возможностью хранения сформированных запросов RPC в совместно используемой структуре данных, доступной менеджеру RPC.

Другими словами, к структуре данных, совместно используемой в среде множества потоков у клиента, можно получать доступ через менеджера RPC. Следовательно, любое выполнение запросов RPC, хранящихся в совместно используемой структуре данных, может выполняться клиентом или менеджером RPC или посредством обмена между клиентом и менеджером. На практике эффективность устройства при внутренней обработке и управлении может быть гибко улучшена.

В десятой форме реализации устройства, соответствующего любому из второй-девятой форм реализации первого варианта, операция, которая должна выполняться, основываясь на запросе RPC, является операцией базы данных и объект является объектом базы данных.

База данных может рассматриваться как техническое поле, в котором операция делает ссылку на операцию базы данных и объект ссылается на объект базы данных. Например, набор операций базы данных может выполняться в базе данных. Операцией базы данных является преобразование базы данных из одного состояния в другое. При таких преобразованиях нет необходимости сохранять совместимость. В последующем примере объектом базы данных является любой определенный объект в базе данных, который используется для хранения ссылочных данных. Например, объектом базы данных является блок данных в базе данных, такой как одно или более полей записи, одна или более записей или одна или более таблиц.

Второй вариант настоящего изобретения обеспечивает систему, содержащую устройство, соответствующее первому варианту настоящего изобретения, и сервер, выполненный с возможностью приема пакета RPC от устройства.

Третий вариант настоящего изобретения обеспечивает способ прогона множества потоков, содержащий этапы, на которых: формируют посредством устройства для каждого из множества потоков запрос RPC на выполнение операции; сохраняют посредством устройства сформированные запросы RPC (в базе данных) в памяти устройства; упорядочивают посредством устройства сохраненные запросы RPC и передают посредством устройства упорядоченные запросы RPC в пакете RPC.

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

Во второй форме реализации способа, соответствующего первой форме реализации третьего варианта, способ дополнительно содержит этап, на котором: определяют посредством устройства для каждого хранящегося запроса RPC по меньшей мере один объект, в котором хранящиеся запросы RPC упорядочиваются, основываясь на времени и определенном объекте.

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

В четвертой форме реализации способа, соответствующего второй форме реализации третьего варианта, способ дополнительно содержит этапы, на которых: упорядочивают все хранящиеся запросы RPC, соответствующие первому объекту, прежде чем упорядочивать хранящийся запрос RPC, соответствующий второму объекту, где по меньшей мере один упорядоченный запрос RPC, соответствующий первому объекту, был сформирован устройством раньше, чем любой упорядоченный запрос RPC, соответствующий второму объекту.

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

В шестой форме реализации способа, соответствующего пятой форме реализации третьего варианта, состояние каждого сформированного запроса RPC является одним из следующих: PENDING (ожидание), SENDABLE (пригодное для посылки), SENT (послано) и COMPLETED (выполнено). Состояние устанавливается как PENDING в момент, когда сформированный запрос RPC сохраняется в структуре данных. Состояние устанавливается как SENDABLE, если упорядоченный запрос RPC, соответствующий объекту, не послан и состояния всех предшествующих посланных запросов RPC, соответствующих упомянутому объекту, устанавливаются как COMPLETED. Состояние устанавливается как SENT, если упорядоченный запрос RPC послан и ответ на упомянутый упорядоченный запрос RPC не получен устройством. Состояние устанавливается как COMPLETED, если ответ на упорядоченный запрос RPC получен.

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

В восьмой форме реализации способа, соответствующего седьмой форме реализации третьего варианта, упорядоченные запросы RPC отправляются серверу, находящемуся вне устройства.

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

В десятой форме реализации способа, соответствующего любой из второй-девятой форм реализации третьего варианта, операция, которая должна выполняться, основываясь на запросе RPC, является операцией базы данных и объект является объектом базы данных.

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

Краткое описание чертежей

Упомянутые выше варианты и формы реализации настоящего изобретения объясняются в последующем описании конкретных вариантов осуществления совместно с приложенными чертежами, на которых:

фиг. 1 - блок-схема устройства, соответствующего варианту осуществления настоящего изобретения;

фиг. 2 - блок-схема системы, соответствующей варианту осуществления настоящего изобретения;

фиг. 3 - способ прогона множества потоков, соответствующий варианту осуществления настоящего изобретения;

фиг. 4 - процесс управления запросами RPC, соответствующий варианту осуществления настоящего изобретения;

фиг. 5 - способ упорядочивания запросов RPC, соответствующий варианту осуществления настоящего изобретения;

фиг. 6 - процесс управления запросами RPC, соответствующий дополнительному варианту осуществления настоящего изобретения.

Подробное описание вариантов осуществления

На фиг. 1 представлена блок-схема, схематично показывающая устройство, соответствующее варианту осуществления настоящего изобретения. Устройство 100 способно к выполнению прогона множества потоков. Устройство 100 может быть любым устройством, поддерживающим процедуру RPC, например, компьютером.

Устройство 100 на фиг. 1 содержит память 101, процессор RPC, который может быть, например, клиентом 103, и менеджера 105 RPC. Клиент 103 и менеджер 105 RPC, соответственно, соединяются с памятью 101. Соединение может поддерживать управление клиентом 103 и менеджером 105 RPC данными, хранящимися в памяти 101, такое как считывание, запись и т. д. Клиент 103 может быть блоком программного обеспечения или аппаратными средствами внутри компьютера и быть выполненным с возможностью осуществления определенных функций. Примеры функций, осуществляемых клиентом 103, приводятся далее.

На фиг. 2 представлена блок-схема, схематично показывающая систему, соответствующую варианту осуществления настоящего изобретения. Система может быть компьютерной системой. Компьютерная система содержит устройство 100 и сервер 200. Сервер 200 может быть устройством, расположенным вне устройства 100, например, удаленным устройством, способным к осуществлению связи с устройством 100. Альтернативно, сервер 200 может быть частью устройства 100, например, блоком, расположенным внутри устройства 100. Другими словами, устройство 100 рассматривается как система и связь между сервером 200 и клиентом 103 осуществляется внутри устройства 100.

Как показано на фиг. 1 и фиг. 2, клиент 103 выполнен с возможностью формирования для каждого из множества потоков запроса RPC на выполнение операции и хранения сформированного запроса RPC в памяти 101. Менеджер 105 RPC выполнен с возможностью упорядочивания хранящихся запросов RPC. Клиент 103 дополнительно выполнен с возможностью посылки упорядоченных запросов RPC в пакете RPC.

В примере, операция, которая должна выполняться, основываясь на запросе RPC, является операцией базы данных и объект является объектом базы данных. Операции базы данных могут выполняться в базе данных и могут определяться как преобразование из одного состояния базы данных в другое. Для таких преобразований нет необходимости сохранять совместимость данных. Объект базы данных может быть любым определенным объектом в базе данных, которая используется для хранения данных или справочных данных. Например, объект базы данных является блоком информации в базе данных, таким как одно или более полей записи, одной или более записями или одной или более таблицами.

На фиг. 3 представлен соответствующий варианту осуществления настоящего изобретения способ прогона множества потоков, который может выполняться устройством 100, как показано на фиг. 1 и фиг. 2. Для каждого из множества потоков клиент 103 формирует запрос RPC на выполнение операции (этап 301) и дополнительно сохраняет сформированный RPC в памяти 101 (этап 303). Менеджер 105 RPC упорядочивает хранящиеся запросы RPC, с тем, чтобы клиент посылал упорядоченные запросы RPC в пакете RPC (этап 305, этап 307).

Устройство 100 может использоваться в многозадачной среде. Наиболее простым таким использованием является многопоточность. Поэтому на этапе 301 один поток у клиента 103 может моделировать множество потоков, чтобы сформировать множество запросов RPC.

В настоящем изобретении нет ограничения, какой поток используется для посылки упорядоченных запросов RPC. Другими словами, упорядоченные запросы RPC могут посылаться в пакете любым потоком, проходящим в устройстве 100. По сравнению с предшествующим уровнем техники, где поток, формирующий запрос RPC, должен посылать запрос RPC и ожидать соответствующего ответа RPC, клиент 103 может послать пакет, содержащий упорядоченные запросы RPC, посредством потока, отличного от того, который использовался при формировании упорядоченных запросов RPC. Потоки, занятые процедурами RPC, могут своевременно освобождаться и использоваться для формирования других запросов RPC. Поэтому эффективность обработки запросов RPC в устройстве 100 увеличивается.

Дополнительно, потоки, проходящие через устройство 100, могут отличаться по своей функциональности. В решении о выделении потока могут быть выделены один или более потоков для осуществления сетевой связи, такой как посылка пакета. Например, для формирования запросов RPC может быть выделено несколько потоков, тогда как для посылки пакета RPC могут быть выделены несколько потоков. Поэтому клиент 103 может быть дополнительно выполнен с возможностью определения конкретного потока или конкретной группы потоков для посылки пакета RPC. Таким образом, может быть обеспечена эффективность обработки запросов RPC в устройстве 100.

Клиент 103 может быть выполнен с возможностью сохранения сформированных запросов RPC в совместно используемой структуре 400 данных, доступной менеджеру 105 RPC. Совместно используемая структура 400 данных может быть базой данных, например, памятью 101.

Устройство 100 может, по мере необходимости, переупорядочить запросы RPC, используя механизм приоритезации, могут быть рассмотрены другой механизм приоритезации и различные параметры. Например, параметр ''время формирования" может придавать более высокое значение приоритета более ранним сформированным запросам RPC. Параметр "качество обслуживания", который связывается с RPC, может придавать более высокое значение приоритета запросам RPC, связываемым с определенным качеством обслуживания. Параметр "размер RPC" может придавать более высокое значение приоритета запросам RPC с определенным размером. Параметр "адрес получателя" может придавать более высокое значение приоритета запросам RPC с определенным адресом получателя.

В последующем варианте осуществления параметром механизма приоритезации является время формирования, то есть, время, когда сформирован запрос RPC.

На фиг. 4 представлен процесс управления запросами RPC, соответствующий варианту осуществления настоящего изобретения. Позиция "Time" (время) на фиг. 4 может, например, указывать часы прогона в системе. Каждый из запросов 1, 2, 3 и 4 RPC соответственно формируются клиентом 103 в моменты времени t1, t2, t3 и t4. Совместно используемая структура 400 данных сохраняет запросы 1, 2, 3 и 4 RPC, сформированные одним из потоков 1, 2 или 3. Менеджер 105 RPC, который может получать доступ к совместно используемой структуре 400 данных, упорядочивает запросы 1, 2, 3 и 4 RPC, основываясь на времени, когда хранящиеся запросы 1, 2, 3 и 4 RPC были сформированы клиентом 103. Клиент 103 посылает пакет Х RPC, содержащий упорядоченные запросы 1, 2, 3 и 4 RPC потоком 4 к серверу в момент время tn, например, в заданное время, когда поток 4 считывает совместно используемую структуру 400 данных, и посылает пакет Х RPC. Клиент непрерывно ведет накопление, чтобы получать ответы RPC, соответствующие запросам RPC, содержащимся в пакете Х RPC.

Если менеджер 105 RPC при ранжировании сохраненного запроса RPC учитывает один параметр, например, время, когда сформирован сохраненный запрос RPC, запросы RPC, содержащиеся в пакете Х RPC, могут иметь показанный на фиг. 4 следующий порядок "запрос 1 RPC 1, сформированный потоком 1 → запрос 2 RPC, сформированный потоком 2, → запрос 3 RPC, сформированный потоком 3 → запрос 4 RPC, сформированный потоком 2". Эта последовательность указывает, как менеджер 105 RPC последовательно упорядочивает запросы 1, 2, 3 и 4 RPC. Например, запрос 1 RPC упорядочивается раньше менеджером 105 RPC. Это означает, что ранг запроса 1 RPC выше, чем ранги запросов 1, 3 и 4 RPC. Поэтому при группировании пакета Х RPC запрос 1 RPC имеет более высокий приоритет по сравнению с запросами 2, 3 и 4 RPC.

Дополнительно, менеджер 105 RPC может быть выполнен с возможностью определения для каждого из хранящихся запросов RPC одного объекта и упорядочивания хранящихся запросов RPC, основываясь на двух параметрах: время, когда был сформирован хранящийся запрос RPC, и определенный объект. Другими словами, ранжирование каждого запроса RPC определяется, основываясь на времени, когда был сформирован сохраненный запрос RPC, и определенном объекте. Порядок запросов RPC в совместно используемой структуре 400 данных определяется, основываясь на ранжировании всех запросов RPC. В частности, менеджер 105 RPC выполнен с возможностью назначения ранга для каждого из запросов RPC, основываясь на времени и объекте. Ранжирование указывает, как запросы RPC упорядочиваются менеджером 105 RPC.

Для заданного объекта запросы RPC, соответствующие объекту, упорядочиваются в соответствии со временем, когда сформированы запросы RPC, как объясняется выше.

Полагая, что запросы 1, 2, 3 и 4 RPC соответствуют одному и тому же объекту, запросы RPC, содержащиеся в пакете Х RPC, могут иметь следующий порядок: "запрос 1 RPC→ запрос 2 RPC → запрос 3 RPC → запрос 4 RPC".

Альтернативно, запросы 1, 2, 3 и 4 RPC могут соответствовать различным объектам. Например, запросы 1 и 3 RPC соответствуют объекту 1, запрос 2 RPC соответствует объекту 2 и запрос 4 RPC соответствует объекту 3. Менеджер 105 RPC может определить, как упорядочивать запросы 1, 2, 3 и 4 RPC, что показано на фиг. 5.

В качестве примера этапа 305, показанного на фиг. 3, на фиг. 5 показан способ упорядочивания запросов RPC в соответствии с вариантом осуществления настоящего изобретения. Таблица 500 содержит информацию о запросах RPC, сформированных клиентом 103. Другими словами, запросы RPC, хранящиеся в совместно используемой структуре 400 данных, могут быть записаны в таблице 500.

Таблица 500 может храниться в памяти 101 и доступна как клиенту 103, так и менеджеру 105 RPC. Таблица 500 может обновляться всякий раз, когда изменяется любой из параметров, связанных с запросом RPC. Другими словами, как клиент 103, так и менеджер 105 RPC могут осуществлять выполнение, связанное с одним или более запросами RPC, в качестве средства запуска обновления таблицы 500. В одном из примеров, таблица 500 обновляется менеджером 105 RPC всякий раз, когда упорядочиваются один или более запросов RPC. В другом примере таблица 500 обновляется клиентом 103 всякий раз, когда сформированы один или более запросов RPC.

Как показано на фиг. 5, менеджер 105 RPC определяет, какой запрос RPC из числа запросов RPC, которые не упорядочены, является самым ранним, сформированным клиентом 103 (этап 501). Менеджер 105 RPC упорядочивает этот самый ранний запрос RPC прежде, чем упорядочивать другие сформированные запросы RPC. Другими словами, менеджер 105 RPC присваивает ранг этому самому раннему запросу RPC, чтобы придать ему самый высокий приоритет среди неупорядоченных запросов RPC, с тем, чтобы упорядочить этот самый ранний запрос RPC. Менеджер 105 RPC 05 может дополнительно соответственно обновить таблицу 500. Например, менеджер 105 RPC присваивает этому самому раннему запросу RPC (например, запросу 1 RPC) ранг "1" в таблице 500.

На этапе 503 менеджер 105 RPC определяет, к какому объекту принадлежит этот самый ранний запрос RPC. Например, определяется и записывается в таблицу 500 объект 1 (не показано на фиг. 5).

На этапе 505, менеджер 105 RPC проверяет, имеются ли другие запросы RPC, соответствующие тому же самому определенному объекту. Если "да", эти запросы RPC упорядочиваются менеджером 105 RPC, основываясь на времени, когда был сформирован каждый запрос RPC. Например, менеджер 105 RPC устанавливает порядок запроса 3 RPC раньше, чем порядок запроса 2 RPC, потому что запрос 3 RPC и запрос 1 RPC принадлежат одному и тому же объекту. Дополнительно, менеджер 105 RPC может соответственно обновить таблицу 500. Например, менеджер 105 RPC назначает в таблице 500 запросу 3 RPC ранг "2".

Если все запросы RPC, соответствующие одному и тому же определенному объекту, упорядочены, менеджер 105 RPC среди всех сформированных, но не упорядоченных запросов RPC, определяет, какой запрос RPC является самым ранним, сформированным клиентом 103. Например, менеджер 105 RPC выполняет процедуру этапов 501, 502 и 503 как итерационный алгоритм. То есть, беря всякий раз, как показано на фиг. 5, различное (обновленное) множество запросов RPC в качестве ввода в процедуру, менеджер 105 RPC непрерывно упорядочивает запросы RPC, хранящиеся в памяти 101, основываясь на таких параметрах, как время и объект.

На фиг. 6 представлен процесс управления запросов RPC, соответствующий дополнительному варианту осуществления настоящего изобретения.

Как показано на фиг. 6, таблица 600 содержит несколько параметров, используемых для управления запросами RPC, хранящимися в совместно используемой структуре 400 данных. Параметрами являются: "время формирования", когда запросы RPC сформированы клиентом 103, "объект", к которому принадлежат запросы RPC, "ранжирование", которое менеджер 105 RPC назначает запросам RPC.

Параметры дополнительно содержат состояние каждого запроса RPC. Состояние может устанавливаться и обновляться клиентом 103 или менеджером 105 RPC. В одном из примеров, клиент 103 устанавливает состояние запроса RPC при сохранении запроса RPC в совместно используемой структуре 400 данных. В другом примере менеджер 105 RPC может обновлять (сбрасывать) состояние запроса RPC, основываясь на состоянии ранее упорядоченных запросов RPC.

Состояние каждого запроса RPC может быть одним из следующих: PENDING (ожидание), SENDABLE (пригодное для посылки), SENT (послано) и COMPLETED (выполнено).

Как показано на фиг. 6, клиент 103 устанавливает каждое состояние PENDING запросов 1-8 RPC в момент, когда каждый из запросов 1-8 RPC сохраняется в совместно используемой структуре 400 данных. Устройство 100 не готово посылать запросы RPC с состоянием PENDING.

Менеджер 105 RPC упорядочивает запросы RPC, например, с помощью способа, показанного выше на фиг. 5, и записывает результаты этапа упорядочивания в позицию "порядок" таблицы 600.

Предположим, что в момент T_A, как показано на фиг. 6, устройством 100 была получена только часть ответов RPC, соответствующих запросам RPC, сформированным раньше, чем запрос 1 RPC. Например, все ответы RPC, соответствующие запросам RPC, принадлежащим объекту 1 и объекту 2, были получены. Ответы RPC, соответствующие запросам RPC, принадлежащим объекту 3, не были получены.

В момент T_A клиент 103 устанавливает состояние всех запросов RPC, принадлежащих объекту 1 (то есть, запросов 1 и 3 RPC), как SENDABLE.

Предположим, что пакет RPC определяется устройством 100 как содержащий больше запросов RPC, например, 6 запросов RPC. В момент T_В клиент 103 дополнительно устанавливает состояние всех запросов RPC, принадлежащих объекту 2 (то есть, запросов 2, 5 и 7 RPC) как SENDABLE.

Все другие упорядоченные запросы RPC, принадлежащие объекту 3 (то есть, запросы 4, 6 и 8 RPC), являются неупорядоченными менеджером 105 RPC в момент T_B. Поскольку ответы RPC, соответствующие ранее сформированным запросам RPC (с состоянием SENT), которые принадлежат объекту 3, не были получены, ни один из запросов 4, 6 и 8 RPC не будет обновляться, то есть, их состояния устанавливаются как SENDABLE, даже когда пакет RPC имеет возможность получить еще один запрос RPC.

Клиент 103 группирует запросы 1, 2, 3, 5 и 7 RPC в пакет RPC, основываясь на их порядке. Дополнительно, клиент 103 посылает пакет RPC на сервер и в момент T_C обновляет состояние запросов 1, 2, 3, 5 и 7 RPC на состояние SENT.

Предположим, что после момента T_C ответы RPC, соответствующие запросам 1, 2, 3 и 5 RPC, были получены устройством 100. В момент T_d клиент 103 устанавливает состояние запросов 1, 2, 3 и 5 RPC как COMPLETED. Состояние запроса 7 RPC сохраняется как SENT, поскольку до момента T_d никакой ответ RPC, соответствующий запросу 7 RPC получен не был.

Дополнительно предположим, что ответы RPC, соответствующие ранее сформированным запросам RPC, принадлежащим объекту 3, также были получены устройством 100 перед T_D. Состояние ранее сформированных запросов RPC, принадлежащих объекту 3, может быть установлено как COMPLETED (не показано на фиг. 6). В момент T_D клиент 103 может установить состояние запросов RPC, принадлежащих объекту 3, то есть, запросов 4, 6 и 8 RPC, как SENDABLE.

Состояние запросов 4, 6 и 8 RPC будет обновлено клиентом 103, когда будет послан пакет RPC, содержащий запросы 4, 6 и 8 RPC.

Параметры, связанные с запросами RPC, являются необязательными и не ограничиваются тем, чтобы одновременно содержаться в одной таблице. Любой механизм, поддерживающий клиента 103 и менеджера 105 RPC при реализации управления запросами RPC, содержится в настоящем изобретении.

В итоге, устройство 100 и способ прогона множества потоков способны повысить эффективность процедуры RPC.

Настоящее изобретение здесь было описано в сочетании с различными вариантами осуществления. Однако, и другие вариации раскрытых вариантов осуществления могут стать понятны и осуществлены специалистами в данной области техники, практически реализующими заявленное настоящее изобретение, исходя из изучения чертежей, раскрытия и приложенной формулы изобретения. В формуле изобретения слово "содержащий" не исключает другие элементы или этапы и единственное число не исключает множественное число. Единый процессор или другой блок могут выполнять функции нескольких элементов, описанных в формуле изобретения. Простой факт, что определенные меры описываются во взаимно различных зависимых пунктах формулы изобретения, не указывает, что сочетание этих мер не может использоваться для достижения преимуществ. Компьютерная программа может храниться/распространяться на соответствующем носителе, таком как оптический носитель или твердотельный носитель, поставляемых вместе или как часть других аппаратных средств, но может также распространяться в других формах, таких как через Интернет или другие проводные или беспроводные системы связи.

Изобретение относится к технологиям сетевой связи. Технический результат заключается в повышении скорости обработки данных. Устройство прогона множества потоков, причем упомянутое устройство содержит: память; клиента, выполненного с возможностью формирования для каждого из множества потоков запроса удаленного вызова процедуры (RPC) для выполнения операции и сохранения сформированного запроса RPC в памяти; и менеджера RPC, выполненного с возможностью упорядочивания сохраненных запросов RPC; в котором клиент дополнительно выполнен с возможностью посылки упорядоченных запросов RPC в пакете RPC посредством прогона потока в устройстве. 3 н. и 18 з.п. ф-лы, 6 ил.

1. Устройство прогона множества потоков, причем упомянутое устройство содержит: память; клиента, выполненного с возможностью формирования для каждого из множества потоков запроса удаленного вызова процедуры (RPC) для выполнения операции и сохранения сформированного запроса RPC в памяти; и менеджера RPC, выполненного с возможностью упорядочивания сохраненных запросов RPC; в котором клиент дополнительно выполнен с возможностью посылки упорядоченных запросов RPC в пакете RPC посредством прогона потока в устройстве.

2. Устройство (100) по п. 1, в котором менеджер RPC выполнен с возможностью упорядочивания хранящихся запросов RPC, основываясь на времени, когда были сформированы сохраненные запросы RPC.

3. Устройство (100) по п. 2, в котором менеджер RPC выполнен с возможностью определения для каждого из сохраненных запросов RPC по меньшей мере одного объекта и упорядочивания сохраненных запросов RPC, основываясь на времени и определенном объекте.

4. Устройство по п. 3, в котором менеджер RPC выполнен с возможностью упорядочивания всех сохраненных запросов RPC, соответствующих первому объекту, прежде чем упорядочивать сохраненный запрос RPC, соответствующий второму объекту, и котором по меньшей мере один упорядоченный запрос RPC, соответствующий первому объекту, был сформирован клиентом раньше любого упорядоченного запроса RPC, соответствующего второму объекту.

5. Устройство по п. 4, в котором состояние каждого сформированного запроса RPC устанавливается при сохранении в структуре данных и после этого обновляется, основываясь на состоянии ранее упорядоченных запросов RPC.

6. Устройство по п. 5, в котором состояние каждого сформированного запроса RPC является одним из следующих: PENDING (ожидание), устанавливаемое в момент, когда сформированный запрос RPC сохранен в структуре данных; SENDABLE (пригодное для посылки), когда упорядоченный запрос RPC, соответствующий объекту, не послан и состояния всех предшествующих посланных запросов RPC, соответствующих упомянутому объекту, устанавливаются как COMPLETED; SENT (послано), когда упорядоченный запрос RPC послан и ответ на упомянутый упорядоченный запрос RPC не получен клиентом; и COMPLETED (выполнено), когда ответ на упорядоченный запрос RPC получен.

7. Устройство по п. 3, в котором все упорядоченные запросы RPC соответствуют одному и тому же объекту.

8. Устройство по п. 1, в котором упорядоченные запросы RPC посылаются серверу, находящемуся вне устройства.

9. Устройство по любому из пп. 1-7, в котором клиент выполнен с возможностью сохранения сформированных запросов RPC в совместно используемой структуре данных, доступной менеджеру RPC.

10. Устройство по любому из пп. 1-7, в котором операция, которая должна быть выполнена, основываясь на запросе RPC, является операцией базы данных и объект является объектом базы данных.

11. Система прогона множества потоков, содержащая: устройство по любому из пп. 1-7; и сервер, выполненный с возможностью получения от устройства пакета RPC.

12. Способ прогона множества потоков, содержащий этапы, на которых: формируют посредством устройства для каждого из множества потоков запрос удаленного вызова процедуры (RPC) для выполнения операции; сохраняют посредством устройства сформированные запросы RPC в памяти устройства; упорядочивают посредством устройства сохраненные запросы RPC и посылают посредством устройства упорядоченные запросы RPC в пакете RPC посредством прогона потока в устройстве.

13. Способ по п. 12, в котором сохраненные запросы RPC упорядочиваются, основываясь на времени, когда были сформированы сохраненные запросы RPC.

14. Способ по п. 13, дополнительно содержащий этап, на котором: определяют посредством устройства для каждого сохраненного запроса RPC по меньшей мере один объект; в котором сохраненные запросы RPC упорядочиваются, основываясь на времени и на определенном объекте.

15. Способ по п. 14, причем упомянутый способ дополнительно содержит этап, на котором: упорядочивают все сохраненные запросы RPC, соответствующие первому объекту, прежде чем упорядочивать сохраненный запрос RPC, соответствующий второму объекту, где по меньшей мере один упорядоченный запрос RPC, соответствующий первому объекту, был сформирован устройством раньше, чем любой упорядоченный запрос RPC, соответствующий второму объекту.

16. Способ по п. 15, в котором состояние каждого сформированного запроса RPC устанавливается, когда запрос сохраняется в структуре данных, и после этого обновляется, основываясь на состоянии ранее упорядоченных запросов RPC.

17. Способ по п. 16, в котором состояние каждого из сформированных запросов RPC является одним из следующих: PENDING (ожидание), устанавливаемое в момент, когда сформированный запрос RPC сохранен в структуре данных; SENDABLE (пригодное для посылки), когда упорядоченный запрос RPC, соответствующий объекту, не послан, и состояния всех предшествующих посланных запросов RPC, соответствующих упомянутому объекту, устанавливаются как COMPLETED; SENT (послано), когда упорядоченный запрос RPC послан и ответ на упомянутый упорядоченный запрос RPC не получен устройством; и COMPLETED (выполнено), когда ответ на упорядоченный запрос RPC получен.

18. Способ по п. 14, в котором все упорядоченные запросы RPC соответствуют одному и тому же объекту.

19. Способ по п. 12, в котором упорядоченные запросы RPC посылаются серверу, находящемуся вне устройства.

20. Способ по любому из пп. 12-18, в котором способ дополнительно содержит этап, на котором: сохраняют сформированные запросы RPC в совместно используемой структуре данных в устройстве, где совместно используемая структура данных доступна как клиенту, так и менеджеру RPC в устройстве.

21. Способ по любому из пп. 12-18, в котором операция, которая должна выполняться, основываясь на запросе RPC, является операцией базы данных и объект является объектом базы данных.