Messages in this thread |  | | Date | Wed, 27 Dec 2000 17:48:21 +0100 | From | "J . A . Magallon" <> | Subject | Re: Semaphores slow??? |
| |
On 2000.12.27 Rogier Wolff wrote: > J . A . Magallon wrote: > > You missed that we push the bs 1000 times before we allow the producer > to start. >
Lets rename write_buffer_sem == holes write_sem == items
So: producer: while (1) { // Wait a hole sem_wait (&holes); ... // Signal we posted an item sem_post (&items); } consumer: for (i=0;i<1000;i++) sem_post (&holes); /* OK, you have 1000 holes fo fill */ while (1) { // Wait an item sem_wait (&items); ... // Say we left a hole sem_post (&holes); }
So you have a finite FIFO of size N, empty at start. There will be a short transient state when: - if producer is faster, queue fills; consumer is 'free-run'-alike, there is always something to eat, but producer blocks him. - if consumer is faster, queue exhausts and it runs as if queue size was 1. There is always hole for a new item, but consumer has to wait a full producer loop to get an item. And you end up in the case of the previous post.
You don't have to keep the queue blocked while you work on items. Try something like: producer: while (1) { ... (prepare item) (and consumer can read items at the same time) // Wait a hole sem_wait (&holes); put item // Signal we posted an item sem_post (&items); } consumer: for (i=0;i<1000;i++) sem_post (&holes); /* OK, you have 1000 holes fo fill */ while (1) { // Wait an item sem_wait (&items); get item // Say we left a hole sem_post (&holes); ... (use item) (and producer can insert items at the same time) }
-- J.A. Magallon $> cd pub mailto:jamagallon@able.es $> more beer
Linux werewolf 2.2.19-pre3-aa3 #3 SMP Wed Dec 27 10:25:32 CET 2000 i686
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |