C言語で処理のスケジューリング

「処理時間の制約が非常に強く・・・」とありますので、例えばハードウェア割り込み処理（短時間で処理を完了してCPUを開放する必要がある）の中で、サーバーへのデータ送信を実行しようとしているが、サーバー側のレスポンスが遅くて完了待ちが発生してしまう、というような状況だと仮定します。

この場合、定番のデザインパターンとして、「送信キュー」という仕組みを作ります。割り込み処理の中ではリクエストメッセージを作成してそれをキューに入れ、ただちに処理を完了させるようにします。そうしておいて、このキューからリクエストメッセージを取り出してサーバーに送信する処理を別スレッドで走らせます。もしサーバーへ送るリクエストの順番を維持したい場合はスレッド数を増やす、リクエストの順番に意味がないのであれば、キューとスレッドをセットで増やすなどの方法で、パフォーマンスを最適化することができます。

「キュー」とは何かということについては、「キューとスタック」などで検索すると多数ヒットします。簡単に言うと、同時多発的に発生するデータを一列に整列させ、FIFO（First in First out／先に列にならんだものを先に）処理するための仕組みです。単純なキューは、構造体やクラスインスタンスの実体かポインタの配列として実装されます。ただし配列要素数が数千や数万の単位で可変長になる場合には、単方向／双方向のオブジェクト参照リストとして実装するほうがパフォーマンス的に有利にできると思います。

クライアント／サーバーシステムで「送信キュー」や（今回は不要ですが）「受信キュー」などの仕組みを使うパターンについては、「メッセージキュー」や「疎結合分散システム」などで検索するとより詳しい情報を得ることができると思います。

ご参考になれば。

セマフォを使って同時リクエスト数を100くらいに制限しては如何でしょうか？
セマフォの内カウンティングセマフォと呼ばれるものが使えると思います。

Windowsならこの辺が参考になると思います。
その他のOSについては私は分かりませんが、linuxもありそうです。

あらかじめスレッドを作成しておいて，親スレッドはリクエストが来たら空いている子スレッドに処理を投げるだけ，子スレッドは受け取ったリクエストをさばく，という実装になっているのでしょうか？

スレッド数を増やせば，空いている子スレッドが無いために親がリクエストを保留するという待ちは減らせるかもしれませんが，同時に実行できるスレッド数にはCPUに依存する限界がありますから，子スレッドがリクエストをさばくためにCPUのスケジューリング待ちをする時間はどうしても存在します．
OSの機能を使って作ったスレッドであればOSのスケジューラに依存しますし，ユーザレベルのスレッド機能を使って作ったスレッドであればそのライブラリか何かのスケジューラに依存します．
一般ユーザレベルスレッドの方が高速に切り替えられると言われているので，互換性は犠牲になりますが，スループットを向上させるためには良いかもしれません．

逆に，子スレッドの空きは十分にあるのに，親スレッドのリクエストのさばき方が悪いために遅くなる場合もあります．
どのような関数でリクエストの到来を待っているのかによって，同時接続数の上限も変動する可能性があります．（Linuxであればselect，poll，epollなどたくさんあります）

まずは，どこがサーバプログラムのボトルネックになっているのかの調査が必要だと思います．
また単一のサーバプログラムで処理をすべて行うためには，上述のような限界もありますので，ロードバランサの導入も検討してみてください．
（「150アクセスごとに分け, スケジューリング」というのはロードバランサのことでしょうか？）

一般的な話になってしまいますが、送受信処理をうまく回すためには、送受信スレッドは1つずつにするのが普通です。つまり、送受信の交通整理を専門で行うスレッドを用意するわけです。送信スレッドは送信に専念し、受信スレッドは受信に専念するわけです。
ハンドシェーク要求を持っているスレッドはそれとは別に（1つないし複数）作成しておき、各ハンドシェークスレッドは送信スレッドにキューなどを使って送信要求を出します。送信スレッドはキューを監視しておいて、データが有ればサーバーにデータを送ります。
受信スレッドは、受信データがあれば各ハンドシェークスレッドに受信データを返します。ただ、ハンドシェークスレッドが複数ある場合は、受信データからどのハンドシェークスレッドに返したらいいのか区別できるようにしておかなければいけません。その辺はデータの内容によって分けることになるのでハンドシェークスレッドの別け方をどうするかということになります。
こうすれば、時間待ち（監視）は各ハンドシェークスレッド個々で行えばいいことになります。各ハンドシェイクスレッドの送信周期も各スレッド毎に制御します。

後は待受が発生したことをどう認識するかですが、サーバー側の話なので基本的には難しいと思います。サーバーに送信するアプリが1つしか無いのであれば送受信数で判断つきますが、サーバーには複数のアプリから要求が来るでしょうから、それを各クライアントが判断するのは基本的には難しく、レスポンス時間で判断するするしか無いように思います。