Looking for an Efficient Thread Synchronization?

Are you using a queue or must each write be followed by a read before the next write can happen?

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

In an application manipulating streaming video and 3D stuff I want to
implement mutithreading to ensure a decent UI response time.

Since my application is very speed critical I want to use the most efficient
synchronization of the shared data objects. What would that be in this case?
I think there's a very simple answer to this, but I am somewhat confused by
the different methods available.

The data I need to transfer between threads share similarities:
- The data only goes one way (streaming); One thread is writing, another
thread is reading.
Only these two threads have access to the object; pretty simple.
- The data transfered per cycle are images and therefore relatively large
chuncks, approximately 1 mb.
- There are up to 30 read/write operations per shared object per second.

Any answer is appreciated (also simple ones)
Looking forward, Teis

There are two fundamental approaches to thread synchronisation. The first
and most common is lock-and-block. The other is message-based. Message-based
is faster but requires more talent.

Set up events on both caller and callee. That way you don't have to wait for
the asynch call to return, the callee can use an event to notify completion
(also asynchronously). Define subclasses of EventArgs to carry your data and
use them for all your parameter passing.

Don't explicitly fire events to call these methods, it's too slow. Call them
directly and have each one start like this so you don't incur the overhead
of asynch marshalling unless you actually need it. Note: functions are
intrinsically blocking. In this case you should use BeginInvoke() and
EndInvoke() to call asynch yet wait for the response. Not as free-wheeling
but still thread-safe.

Or rewrite your functions to return their values in EventArgs via asynch
callback. That's what I do. But you'd better be good at programming - you
can't depend on things happening in a fixed order.

delegate MyMethodDelegate(...);
event MyMethodDelegate MyMethodEvent(...);
void MyMethod(...) {
if (InvokeRequired) {
MyMethodEvent(...);
return;
}
//actual processing
...
}

Thanks you for ansering my post,

there are two different behaveiours
- In some parts, such as reading the video stream, I need to process every
single frame data. A queue sounds suitable for this task.

- In other pards, such as rendering to the UI, I just need the latest data.
The UI has a lot to do and might ask(!) for the data less frequent than
offered by the stream and should then just have the last frame. If it asks
more frequent than offered, it should be told to reuse the last frame.

Regards, Teis
"Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> wrote in
message news:OR****************@TK2MSFTNGP11.phx.gbl...

Are you using a queue or must each write be followed by a read before the next write can happen?
Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

In an application manipulating streaming video and 3D stuff I want to
implement mutithreading to ensure a decent UI response time.

Since my application is very speed critical I want to use the most efficient synchronization of the shared data objects. What would that be in this case? I think there's a very simple answer to this, but I am somewhat confused by the different methods available.

The data I need to transfer between threads share similarities:
- The data only goes one way (streaming); One thread is writing, another
thread is reading.
Only these two threads have access to the object; pretty simple.
- The data transfered per cycle are images and therefore relatively large
chuncks, approximately 1 mb.
- There are up to 30 read/write operations per shared object per second.

Any answer is appreciated (also simple ones)
Looking forward, Teis

Thank you very much for your detailed answer! Very instructive reading.

Or rewrite your functions to return their values in EventArgs via asynch
callback. That's what I do. But you'd better be good at programming.... - Dang!
Note: functions are intrinsically blocking. Do you mean that I can implement lock-and-blocking by encapsulating access
to a specific variable in a single method to ensure that the variable is
only accessed once at a time?... Will this approach exclude me from the
community in all future?
Otherwise can you provide me with standard way to implement simple
lock-and-block?
Don't explicitly fire events to call these methods, it's too slow. Call them directly and have each one start like this so you don't incur the overhead
of asynch marshalling unless you actually need it. Do you have a reference to a code sample for using technique? (Sorry... I'm
still new to threads and will most likely screw up anything, being on my
own).
Thanks yet again, Teis

"Peter Wone" <pe****@wamoz.com> wrote in message
news:OL****************@TK2MSFTNGP14.phx.gbl... There are two fundamental approaches to thread synchronisation. The first
and most common is lock-and-block. The other is message-based. Message-based is faster but requires more talent.

Set up events on both caller and callee. That way you don't have to wait for the asynch call to return, the callee can use an event to notify completion (also asynchronously). Define subclasses of EventArgs to carry your data and use them for all your parameter passing.

Don't explicitly fire events to call these methods, it's too slow. Call them directly and have each one start like this so you don't incur the overhead
of asynch marshalling unless you actually need it. Note: functions are
intrinsically blocking. In this case you should use BeginInvoke() and
EndInvoke() to call asynch yet wait for the response. Not as free-wheeling
but still thread-safe.

Or rewrite your functions to return their values in EventArgs via asynch
callback. That's what I do. But you'd better be good at programming - you
can't depend on things happening in a fixed order.

delegate MyMethodDelegate(...);
event MyMethodDelegate MyMethodEvent(...);
void MyMethod(...) {
if (InvokeRequired) {
MyMethodEvent(...);
return;
}
//actual processing
...
}

Teis Draiby <te*************@draiby.com> wrote:

In an application manipulating streaming video and 3D stuff I want to
implement mutithreading to ensure a decent UI response time.
<snip>
- There are up to 30 read/write operations per shared object per
second.

This is the important bit, I think. If you only need synchronization
about 30 times per second, you don't need to be as efficient as
possible. It's much easier to write good threading code if you don't
require it to be absolutely as fast as possible.

The code which probably *does* need to be fast is the data transfer
part - that's a different matter.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Hi...
Then, maybe a blocking situation is that unlikely to occour frequently that
there is no remarkable overhead just using a simple lock-and-block.

regards, Teis


"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Teis Draiby <te*************@draiby.com> wrote:

In an application manipulating streaming video and 3D stuff I want to
implement mutithreading to ensure a decent UI response time.

<snip>

- There are up to 30 read/write operations per shared object per
second.

This is the important bit, I think. If you only need synchronization
about 30 times per second, you don't need to be as efficient as
possible. It's much easier to write good threading code if you don't
require it to be absolutely as fast as possible.

The code which probably *does* need to be fast is the data transfer
part - that's a different matter.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Hi...
Then, maybe a blocking situation is that unlikely to occour frequently that
there is no remarkable overhead just using a simple lock-and-block.

regards, Teis


"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Teis Draiby <te*************@draiby.com> wrote:

In an application manipulating streaming video and 3D stuff I want to
implement mutithreading to ensure a decent UI response time.

<snip>

- There are up to 30 read/write operations per shared object per
second.

This is the important bit, I think. If you only need synchronization
about 30 times per second, you don't need to be as efficient as
possible. It's much easier to write good threading code if you don't
require it to be absolutely as fast as possible.

The code which probably *does* need to be fast is the data transfer
part - that's a different matter.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Teis,

When I understand you well, can it in my opinion only be efficient what you
try to do is when your deliverer gives only a certain bandwidth for one
stream.

It is in my opinion not efficient for a diskstream, than it is probably more
busy handling the parts you need to read than the actual stream, which reads
the most efficient when there are no other threads who interrupt every time
the reading and that the disk needs to be positioned again.

Just my thought,

Cor

Hi Cor,
The stream is either a live camera stream or from footage already loaded
into memory. I'm not sure about what you're suggesting, but it seems that it
only applies if I am streaming from disk. Is that true?

,teis

"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2*****************@TK2MSFTNGP11.phx.gbl...

Teis,

When I understand you well, can it in my opinion only be efficient what you try to do is when your deliverer gives only a certain bandwidth for one
stream.

It is in my opinion not efficient for a diskstream, than it is probably more busy handling the parts you need to read than the actual stream, which reads the most efficient when there are no other threads who interrupt every time the reading and that the disk needs to be positioned again.

Just my thought,

Cor

Teis,

What I wrote was mainly as it comes from disk yes, however that camera goes
in my opinion as well over one port and I see no interupts directly in that
on the computer side where multithreading will help. My idea is that the
camera is the slowest part. For memory you have it in memory so what is it
that part that you want to improve streaming there. Even when you have a
multiprocessor or hypertreading I think that the synchronization cost you
much more than the streaming.

I am a little bit confused why you want to use threading in this and what
benefit you expect, not only for you however as well for myself.

Cor