soft and program: comp.programming.threads - 13 new messages in 5 topics

comp.programming.threads
http://groups.google.com/group/comp.programming.threads?hl=en

comp.programming.threads@googlegroups.com

Today's topics:

* Welcome to our site: www.ec21baba.com we are a leading company in dealing
with brand shoes - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/4d09ad70ae294d71?hl=en
* Traversing C++ objects using gdb - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/a6887596f9f715a5?hl=en
* Should pthread_exit() be used in main()? - 4 messages, 2 authors
http://groups.google.com/group/comp.programming.threads/t/6f5af4a14c06e2b3?hl=en
* possible problem with pthread mutexes, looking for opinions - 2 messages, 2
authors
http://groups.google.com/group/comp.programming.threads/t/de9d97d417bb51f2?hl=en
* Producer-Consumer problem, but the producer updates the old buffers. - 5
messages, 2 authors
http://groups.google.com/group/comp.programming.threads/t/d7b87f008ad8252a?hl=en

==============================================================================
TOPIC: Welcome to our site: www.ec21baba.com we are a leading company in
dealing with brand shoes
http://groups.google.com/group/comp.programming.threads/t/4d09ad70ae294d71?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jun 3 2009 9:18 pm
From: "jinguo_007@foxmail.com"

Welcome to our site: www.ec21baba.com we are a leading company in
dealing with brand shoes

Welcome to our site: www.ec21baba.com we are a leading company in
dealing with brand shoes (cheap air jordan 1-23, cheap air force
1s,cheap air max,cheap dunk sb,cheap nike shox, rift,adidas,
gucci,bape,iceream, puma, timberland,prada,converse,etc), bags, jeans
(red monkey, Evisu,Lrg , etc), T-shirts (Polo,lacosate, DG, prada,
etc), hats,sun glasses,etc. We can provide all kind of series shoes
and others in my website and keep updating our stock with new colors
and styles. All the shoes are packaged with original box come with the
paper work, logo, tags etc. And style code number is 100% correct.
Free shipment. Hope to cooperate with you and look forward to your
early reply!

URL http://www.ec21baba.com
Thank you
Ec21baba

==============================================================================
TOPIC: Traversing C++ objects using gdb
http://groups.google.com/group/comp.programming.threads/t/a6887596f9f715a5?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jun 4 2009 1:24 am
From: Dmitry

Hi,

I'm debugging a C++ program on Linux. I have an address of some
object. I want using gdb to find what objects holds it.

For example A --holds --> B. I have an address of object B. I want to
find with help of gdb is that B is hold by A.

Thanks
Dima

==============================================================================
TOPIC: Should pthread_exit() be used in main()?
http://groups.google.com/group/comp.programming.threads/t/6f5af4a14c06e2b3?hl=en
==============================================================================

== 1 of 4 ==
Date: Thurs, Jun 4 2009 3:57 am
From: Dave Butenhof

Sunnz wrote:
> Dave Butenhof 提到:
>>
>> Aside from that, if your application architecture is such that it
>> makes sense to cause the current thread to terminate other than by
>> returning from the start routine, call pthread_exit(). If not... don't
>> worry about it.
>>
>> Specifically; in the example you cite, the pthread_exit() call from
>> PrintHello(), which is the thread start routine, is redundant; it
>> could just as easily have simply returned with the value NULL.
>
> Right, so if "return NULL" was written in PrintHello() instead of
> pthread_exit(), then it will implicitly call pthread_exit()?

Let's say, at the risk of complication (but in the interest of
accuracy), simply that the net effect on the process state is the same
either way. Whether there's an ACTUAL call to pthread_exit() on return
from the start routine is unspecified, and irrelevant.

> So what actually would happen here when it calls pthread_exit() but
> doesn't have a return? Would it simply terminate the thread without
> returning anything? If so would it make more sense for start routines
> that doesn't return anything?

I'm not sure what you mean here. A thread start routine always returns a
value of type 'void *'. That is, even if your function doesn't return a
value (and you have a compiler that doesn't mind, or you've deliberately
used the wrong function prototype and either cast the function pointer
on pthread_create or, again, the compiler doesn't mind the mismatch),
the pthread library will interpret the appropriate location (register,
stack, or whatever depending on the machine call architecture) as a
return value, and store that to be queried by pthread_join().

That is, thread start functions ALWAYS return a value.

Calling pthread_exit(), which takes a similar void* value, will have the
same net effect on the internal pthread library data; and that value
will be made available to callers of pthread_join(). Again, if you
manage to fool the compiler to dispatch to the pthread_join entry point
without explicitly specifying a return value for the thread, the
function will still process an argument from the appropriate place; this
merely has an undefined value. (And I use the word "undefined" here
instead of "unspecified" in the strict standardese sense: for some call
architectures such an incorrect call could even result in a memory
access trap rather than merely an arbitrary value.)

In short, you CAN'T terminate a POSIX thread "without returning
anything"... it's not possible. By "fooling" the compiler you can write
code that you can pretend doesn't return anything; but there's still a
return value, and the thread library will handle it just the same.

>> However, main(), except for the call stack arrangement that happens to
>> lead to the implicit exit() call on return, is no different from any
>> other thread. If you want 4 threads each running PrintHello(), and you
>> have nothing in particular for the initial thread to do after
>> launching other threads, you might as well make IT one of those 4 by
>> simply making (NUM_THREADS - 1) calls to pthread_create(), and then
>> calling PrintHello() with an appropriate argument. When the call
>> returns to main(), it can wait for the other threads to finish and
>> exit, or simply call pthread_exit() to let the process terminate
>> passively when the last is done. This performs the same job with less
>> overhead. (Not that the overhead of thread creation is important in
>> this trivial I/O bound example.)
>
> Thanks a lot for the clear explanation and the tips it surely helps a
> lot for beginners like me!! :D

You're welcome. (And I hope the details you've provoked in the follow up
haven't made things a whole lot less clear. ;-) )

== 2 of 4 ==
Date: Thurs, Jun 4 2009 8:29 am
From: andrew@cucumber.demon.co.uk (Andrew Gabriel)

In article <h05ikv$ffk$1@usenet01.boi.hp.com>,
Dave Butenhof <david.butenhof@hp.com> writes:
> Sunnz wrote:
>> Hi,
>>
>> I just started learning pthreads, and are little confused with
>> pthread_exit(), namely, when should it be used?
>>
>> I have written very basic codes to try to understand how it works:
>> http://pastebin.com/m79438632
>>
>> Here if you comment out pthread_exit() in main(), all the child threads
>> don't get to finish, unless you uncomment the for loop that joins all
>> child threads.
>>
>> So does pthread_exit() does that for you? That the process and its
>> threads doesn't get killed till all threads has 'finished'?
>>
>> Should PrintHello in the above example call pthread_exit()?
>
> pthread_exit() causes the calling thread to terminate; just as calling
> exit() causes the process to terminate.
>
> Just as a process returning from main() implicitly calls exit(), most
> threads implicitly call pthread_exit() on return from the thread start
> routine. The exception is the initial thread, the one running main();
> because if we had changed that behavior it would have affected existing
> non-threaded programs as well.
>
> So if you want the initial process thread to terminate, leaving other
> threads in the process to continue operation, you need to explicitly
> call pthread_exit() rather than returning from main().

If no other thread is going to collect its exit status with a
pthread_join() you might want to detach it first for neatness
so you don't end up with a zombie thread...

pthread_detach(pthread_self());
pthread_exit(NULL);

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

== 3 of 4 ==
Date: Thurs, Jun 4 2009 9:37 am
From: Dave Butenhof

Andrew Gabriel wrote:
> In article <h05ikv$ffk$1@usenet01.boi.hp.com>,
>> So if you want the initial process thread to terminate, leaving other
>> threads in the process to continue operation, you need to explicitly
>> call pthread_exit() rather than returning from main().
>
> If no other thread is going to collect its exit status with a
> pthread_join() you might want to detach it first for neatness
> so you don't end up with a zombie thread...
>
> pthread_detach(pthread_self());
> pthread_exit(NULL);

Thereby adding, in neat order, the next level of complication. ;-)

And, to follow up on that, the second argument to pthread_create is a
pointer to an initialized pthread_attr_t; and if you know from the start
you'll have no need to join with a thread, simply create it detached in
the first place by using

pthread_attr_r attr;
pthread_attr_init(&attr);
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
pthread_create(&tid, &attr, start, arg);

Of course, this would mean you have no choice to but terminate your
initial thread with pthread_exit()... because the other threads are
detached, you have no way to know when they're finished.

(Strictly, speaking, adding the next layer, there are plenty of ways to
synchronize with completion of a thread, and pthread_join represents
just one convenient example for the specific case where you care when
the thread is done and want a single value castable to (void*) from it.
There are a million other ways you could make the initial thread know
when the workers had finished, if you wanted; either more general or
possibly even more efficient.)

In your example, there's no point in detaching the threads. Either the
initial thread is exiting with pthread_exit(), and the process will
simply passively terminate when the last thread goes away; or you want
to join with each thread and terminate the process with a specific
status after the last one is done. In the first case, it doesn't matter
whether they're detached; in the second, if you detach you'd only need
to code the equivalent of pthread_join() yourself.

== 4 of 4 ==
Date: Thurs, Jun 4 2009 3:18 pm
From: andrew@cucumber.demon.co.uk (Andrew Gabriel)

In article <h08t7f$10k$1@usenet01.boi.hp.com>,
Dave Butenhof <david.butenhof@hp.com> writes:
> Andrew Gabriel wrote:
>> In article <h05ikv$ffk$1@usenet01.boi.hp.com>,
>>> So if you want the initial process thread to terminate, leaving other
>>> threads in the process to continue operation, you need to explicitly
>>> call pthread_exit() rather than returning from main().
>>
>> If no other thread is going to collect its exit status with a
>> pthread_join() you might want to detach it first for neatness
>> so you don't end up with a zombie thread...
>>
>> pthread_detach(pthread_self());
>> pthread_exit(NULL);
>
> Thereby adding, in neat order, the next level of complication. ;-)

I'm referring specifically to the case above, of the main thread
terminating.

> And, to follow up on that, the second argument to pthread_create is a
> pointer to an initialized pthread_attr_t; and if you know from the start
> you'll have no need to join with a thread, simply create it detached in
> the first place by using
>
> pthread_attr_r attr;
> pthread_attr_init(&attr);
> pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
> pthread_create(&tid, &attr, start, arg);
>
> Of course, this would mean you have no choice to but terminate your
> initial thread with pthread_exit()... because the other threads are
> detached, you have no way to know when they're finished.
>
> (Strictly, speaking, adding the next layer, there are plenty of ways to
> synchronize with completion of a thread, and pthread_join represents
> just one convenient example for the specific case where you care when
> the thread is done and want a single value castable to (void*) from it.
> There are a million other ways you could make the initial thread know
> when the workers had finished, if you wanted; either more general or
> possibly even more efficient.)
>
> In your example, there's no point in detaching the threads. Either the
> initial thread is exiting with pthread_exit(), and the process will
> simply passively terminate when the last thread goes away; or you want
> to join with each thread and terminate the process with a specific
> status after the last one is done. In the first case, it doesn't matter
> whether they're detached; in the second, if you detach you'd only need
> to code the equivalent of pthread_join() yourself.

A reason for terminating the main thread is that you don't get
the opportunity to set it up with non-default attributes, and if
all your threads are going to need specific attributes, then the
main thread may be of no use once it's started up the others.
Leaving it as a zombie means it continues to appear marked as such
in things like "prstat -L", but as I said, it's only for neatness.

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

==============================================================================
TOPIC: possible problem with pthread mutexes, looking for opinions
http://groups.google.com/group/comp.programming.threads/t/de9d97d417bb51f2?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Jun 4 2009 5:53 am
From: Hallvard B Furuseth

Chris Friesen writes:
> 1)We have instrumented code of the following form:
> (...)
> I can think of three ways for the assertion to happen: 1) a thread that
> isn't the owner is calling the unlock wrapper, or 2) there is a
> compiler/pthread bug such that another thread is calling lock_wrapper
> and the lockcounter increment is being hoisted before the lock, 3) the
> underlying lock implementation is buggy.
>
> Did I miss anything?

4) A thread calls the lock wrapper when it already owns the mutex.
5) Destroying the mutex while it's still in use, either via
pthread_mutex_destroy() or by freeing the memory which contains it.
6) Using the lock uninitialzed.
7) Using pthread_cond_wait() - it unlocks/locks the mutex without
going via the wrapper.

When I wanted pthread wrappers to track such problems, I wrapped
pthread_mutex & co in structs that included a dummy memory pointer.
Malloc it at init, access before use, free at destroy. Allowed me to
run it under valgrind and have it report where detected problems were
coming from - either as memory leaks or as invalid memory accesses.

The code may suffer from bitrot. It does suffer from heavy macro magic,
as it's a wrapper around a wrapper thread implementations, but anyway:

http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap_r/thr_debug.c
http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap_r/ldap_thr_debug.h
http://www.openldap.org/devel/cvsweb.cgi/include/ldap_pvt_thread.h
http://www.openldap.org/devel/cvsweb.cgi/include/ldap_int_thread.h

Generally, read 'ldap_pvt_thread_' as 'pthread_' (or the exported
interface resembling it), 'ldap_int_thread_' as internal functions
or wrappers, 'ldap_debug_thread_' as wrappers around wrappers when
some of that couldn't be hidden by macros.

--
Hallvard

== 2 of 2 ==
Date: Thurs, Jun 4 2009 4:09 pm
From: Chris Friesen

Chris M. Thomasson wrote:
> BTW, what platform and architecture is this application failing under?

glibc/linux. The first problem I brought up is failing on mips (32bit
userspace, 64bit kernel). The second is showing up on both mips and x86
(also 32-bit userspace, 64bit kernel).

To add complexity to the mix, glibc and the kernel have been patched
(not by me) to support priority inheritance since the versions in
question are old enough that they didn't originally support it.

In any case, I have some more debugging information now and the app is
running with added instrumentation.

Chris

==============================================================================
TOPIC: Producer-Consumer problem, but the producer updates the old buffers.
http://groups.google.com/group/comp.programming.threads/t/d7b87f008ad8252a?hl=en
==============================================================================

== 1 of 5 ==
Date: Thurs, Jun 4 2009 1:25 pm
From: janesconference@gmail.com

Hi to all,
Let's say I have two buffers. Producer fills buffer #1, then fills
buffer #2. The consumer consumes one buffer a time, and it's very
slow. While it is reading buffer #1, the producer is ready to fill
another buffer, but they are all full, and the consumer hasn't
finished yet with #1. So, the producer waits.

Instead of waiting, I want the producer to update the "free" buffer.
That is, while the consumer is consuming buffer #1, the producer
should write new data on buffer #2 as soon as it has it ready (the
"old" data is overwritten and lost). If the consumer hasn't finished
yet with #1, and the producer has more data to write, it should write
*again* on #2, and so on.
When the consumer finally consumes all the data in #1, it should
immediately start to consume the freshly-written data in buffer #2,
and the producer should keep on updating #1.

This scenery may sound a little strange, but imagine the producer is
acquiring video frames from a CCD at high speed, while the consumer is
slowly elaborating them; the consumer doesn't mind if it skips some
frame, but it must always process the last frame acquired. The
producer, instead, cannot slow down nor wait, because it must acquire
all the frames.

Is there a way to do this kind of thing with semaphores? Is it a well-
known concurrency scenario? And, in case, is it possible to extend
this problem to n > 2 buffers?

Thanks,
Chris.

== 2 of 5 ==
Date: Thurs, Jun 4 2009 1:56 pm
From: Eric Sosman

janesconference@gmail.com wrote:
> Hi to all,
> Let's say I have two buffers. Producer fills buffer #1, then fills
> buffer #2. The consumer consumes one buffer a time, and it's very
> slow. While it is reading buffer #1, the producer is ready to fill
> another buffer, but they are all full, and the consumer hasn't
> finished yet with #1. So, the producer waits.
>
> Instead of waiting, I want the producer to update the "free" buffer.
> That is, while the consumer is consuming buffer #1, the producer
> should write new data on buffer #2 as soon as it has it ready (the
> "old" data is overwritten and lost). If the consumer hasn't finished
> yet with #1, and the producer has more data to write, it should write
> *again* on #2, and so on.
> When the consumer finally consumes all the data in #1, it should
> immediately start to consume the freshly-written data in buffer #2,
> and the producer should keep on updating #1.
>
> This scenery may sound a little strange, but imagine the producer is
> acquiring video frames from a CCD at high speed, while the consumer is
> slowly elaborating them; the consumer doesn't mind if it skips some
> frame, but it must always process the last frame acquired. The
> producer, instead, cannot slow down nor wait, because it must acquire
> all the frames.
>
> Is there a way to do this kind of thing with semaphores? Is it a well-
> known concurrency scenario? And, in case, is it possible to extend
> this problem to n > 2 buffers?

It sounds straightforward, unless I'm failing to understand
something. I think you can do it with any plural number of
buffers (but I'd recommend at least three) and a pair of queues,
one for "filled" buffers and one for "empty" buffers:

Consumer: Remove the first buffer from the "filled" queue
(if there isn't one yet, wait). Process the buffer, then
append it to the "empty" queue. Repeat.

Producer: Remove the first buffer from the "empty" queue.
If there isn't one, remove the first (oldest) buffer from
the "filled" queue. Fill the buffer (wherever it came from),
then append it to the "filled" queue. Repeat.

--
Eric.Sosman@sun.com

== 3 of 5 ==
Date: Thurs, Jun 4 2009 2:59 pm
From: janesconference@gmail.com

Many thanks, only I was looking for the semaphore solution (I'm forced
to use posix-semaphores).

On 4 Giu, 22:56, Eric Sosman <Eric.Sos...@sun.com> wrote:
> janesconfere...@gmail.com wrote:
> > Hi to all,
> > Let's say I have two buffers. Producer fills buffer #1, then fills
> > buffer #2. The consumer consumes one buffer a time, and it's very
> > slow. While it is reading buffer #1, the producer is ready to fill
> > another buffer, but they are all full, and the consumer hasn't
> > finished yet with #1. So, the producer waits.
>
> > Instead of waiting, I want the producer to update the "free" buffer.
> > That is, while the consumer is consuming buffer #1, the producer
> > should write new data on buffer #2 as soon as it has it ready (the
> > "old" data is overwritten and lost). If the consumer hasn't finished
> > yet with #1, and the producer has more data to write, it should write
> > *again* on #2, and so on.
> > When the consumer finally consumes all the data in #1, it should
> > immediately start to consume the freshly-written data in buffer #2,
> > and the producer should keep on updating #1.
>
> > This scenery may sound a little strange, but imagine the producer is
> > acquiring video frames from a CCD at high speed, while the consumer is
> > slowly elaborating them; the consumer doesn't mind if it skips some
> > frame, but it must always process the last frame acquired. The
> > producer, instead, cannot slow down nor wait, because it must acquire
> > all the frames.
>
> > Is there a way to do this kind of thing with semaphores? Is it a well-
> > known concurrency scenario? And, in case, is it possible to extend
> > this problem to n > 2 buffers?
>
> It sounds straightforward, unless I'm failing to understand
> something. I think you can do it with any plural number of
> buffers (but I'd recommend at least three) and a pair of queues,
> one for "filled" buffers and one for "empty" buffers:
>
> Consumer: Remove the first buffer from the "filled" queue
> (if there isn't one yet, wait). Process the buffer, then
> append it to the "empty" queue. Repeat.
>
> Producer: Remove the first buffer from the "empty" queue.
> If there isn't one, remove the first (oldest) buffer from
> the "filled" queue. Fill the buffer (wherever it came from),
> then append it to the "filled" queue. Repeat.
>
> --
> Eric.Sos...@sun.com

== 4 of 5 ==
Date: Thurs, Jun 4 2009 3:21 pm
From: Eric Sosman

make sense of a discussion that runs backwards.
By the way, top-posting is really annoying, because it's hard to

semaphore. When it's finished adding or removing a buffer, sem_post().
consumer wants access to the queue, do a sem_wait() on the appropriate
for each queue, initialized to one. When either the producer or the
So go ahead and use them; nobody's stopping you. Use one semaphore

janesconference@gmail.com wrote:
> Many thanks, only I was looking for the semaphore solution (I'm forced
> to use posix-semaphores).
>
> On 4 Giu, 22:56, Eric Sosman <Eric.Sos...@sun.com> wrote:
>> janesconfere...@gmail.com wrote:
>>> Hi to all,
>>> Let's say I have two buffers. Producer fills buffer #1, then fills
>>> buffer #2. The consumer consumes one buffer a time, and it's very
>>> slow. While it is reading buffer #1, the producer is ready to fill
>>> another buffer, but they are all full, and the consumer hasn't
>>> finished yet with #1. So, the producer waits.
>>> Instead of waiting, I want the producer to update the "free" buffer.
>>> That is, while the consumer is consuming buffer #1, the producer
>>> should write new data on buffer #2 as soon as it has it ready (the
>>> "old" data is overwritten and lost). If the consumer hasn't finished
>>> yet with #1, and the producer has more data to write, it should write
>>> *again* on #2, and so on.
>>> When the consumer finally consumes all the data in #1, it should
>>> immediately start to consume the freshly-written data in buffer #2,
>>> and the producer should keep on updating #1.
>>> This scenery may sound a little strange, but imagine the producer is
>>> acquiring video frames from a CCD at high speed, while the consumer is
>>> slowly elaborating them; the consumer doesn't mind if it skips some
>>> frame, but it must always process the last frame acquired. The
>>> producer, instead, cannot slow down nor wait, because it must acquire
>>> all the frames.
>>> Is there a way to do this kind of thing with semaphores? Is it a well-
>>> known concurrency scenario? And, in case, is it possible to extend
>>> this problem to n > 2 buffers?
>> It sounds straightforward, unless I'm failing to understand
>> something. I think you can do it with any plural number of
>> buffers (but I'd recommend at least three) and a pair of queues,
>> one for "filled" buffers and one for "empty" buffers:
>>
>> Consumer: Remove the first buffer from the "filled" queue
>> (if there isn't one yet, wait). Process the buffer, then
>> append it to the "empty" queue. Repeat.
>>
>> Producer: Remove the first buffer from the "empty" queue.
>> If there isn't one, remove the first (oldest) buffer from
>> the "filled" queue. Fill the buffer (wherever it came from),
>> then append it to the "filled" queue. Repeat.

--
Eric.Sosman@sun.com

== 5 of 5 ==
Date: Thurs, Jun 4 2009 3:23 pm
From: janesconference@gmail.com

On 5 Giu, 00:21, Eric Sosman <Eric.Sos...@sun.com> wrote:
> make sense of a discussion that runs backwards.
> By the way, top-posting is really annoying, because it's hard to
>
> semaphore. When it's finished adding or removing a buffer, sem_post().
> consumer wants access to the queue, do a sem_wait() on the appropriate
> for each queue, initialized to one. When either the producer or the
> So go ahead and use them; nobody's stopping you. Use one semaphore
>
>
>
> janesconfere...@gmail.com wrote:
> > Many thanks, only I was looking for the semaphore solution (I'm forced
> > to use posix-semaphores).
>
> > On 4 Giu, 22:56, Eric Sosman <Eric.Sos...@sun.com> wrote:
> >> janesconfere...@gmail.com wrote:
> >>> Hi to all,
> >>> Let's say I have two buffers. Producer fills buffer #1, then fills
> >>> buffer #2. The consumer consumes one buffer a time, and it's very
> >>> slow. While it is reading buffer #1, the producer is ready to fill
> >>> another buffer, but they are all full, and the consumer hasn't
> >>> finished yet with #1. So, the producer waits.
> >>> Instead of waiting, I want the producer to update the "free" buffer.
> >>> That is, while the consumer is consuming buffer #1, the producer
> >>> should write new data on buffer #2 as soon as it has it ready (the
> >>> "old" data is overwritten and lost). If the consumer hasn't finished
> >>> yet with #1, and the producer has more data to write, it should write
> >>> *again* on #2, and so on.
> >>> When the consumer finally consumes all the data in #1, it should
> >>> immediately start to consume the freshly-written data in buffer #2,
> >>> and the producer should keep on updating #1.
> >>> This scenery may sound a little strange, but imagine the producer is
> >>> acquiring video frames from a CCD at high speed, while the consumer is
> >>> slowly elaborating them; the consumer doesn't mind if it skips some
> >>> frame, but it must always process the last frame acquired. The
> >>> producer, instead, cannot slow down nor wait, because it must acquire
> >>> all the frames.
> >>> Is there a way to do this kind of thing with semaphores? Is it a well-
> >>> known concurrency scenario? And, in case, is it possible to extend
> >>> this problem to n > 2 buffers?
> >> It sounds straightforward, unless I'm failing to understand
> >> something. I think you can do it with any plural number of
> >> buffers (but I'd recommend at least three) and a pair of queues,
> >> one for "filled" buffers and one for "empty" buffers:
>
> >> Consumer: Remove the first buffer from the "filled" queue
> >> (if there isn't one yet, wait). Process the buffer, then
> >> append it to the "empty" queue. Repeat.
>
> >> Producer: Remove the first buffer from the "empty" queue.
> >> If there isn't one, remove the first (oldest) buffer from
> >> the "filled" queue. Fill the buffer (wherever it came from),
> >> then append it to the "filled" queue. Repeat.
>
> --
> Eric.Sos...@sun.com

ROTFL. Thanks (i don't even know why I top posted :).

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.programming.threads"
group.

To post to this group, visit http://groups.google.com/group/comp.programming.threads?hl=en

To unsubscribe from this group, send email to comp.programming.threads+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.programming.threads/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

soft and program

Friday, June 5, 2009

comp.programming.threads - 13 new messages in 5 topics - digest

No comments:

Blog Archive

About Me