Should I use threads when an event is filling a buffer?

[HONOREDANCESTOR]

I am modifying some code that uses 'events' to add to a buffer.
Suppose I want to write a routine that will read from the buffer at
timed intervals. Is there a danger that when I read from the buffer,
an event will suddenly be raised in the middle of my read, and that
event will modify the buffer?
And would using threads prevent this?
Thanks,
-- HA
Note: My read actually should remove info from the buffer as it reads
- so its modifying the buffer.

 

[Tom Shelton]

I am modifying some code that uses 'events' to add to a buffer.
Suppose I want to write a routine that will read from the buffer at
timed intervals. Is there a danger that when I read from the buffer,
an event will suddenly be raised in the middle of my read, and that
event will modify the buffer?
And would using threads prevent this?
Thanks,
-- HA
Note: My read actually should remove info from the buffer as it reads
- so its modifying the buffer.

Your question is difficult to give a straight answer to. You see,
events are really methods and are usually executed on the same thread
that they are raised on (this can be changed by using an async
delegate). So, your question depends on the architecture of you
application. Are you using threads? ThreadPool? Async delegates?
The system.windows.forms.timer is single threaded, but other timers
are not.

Basically, more info is needed to really give complete answer....

 

[Cor Ligthert [MVP]]

Hi,

To add a little bit to Tom, multithreading is only possible if there are
parallel processes.

If your application has to wait until the buffer is filled than
multithreading can only be to keep the closing box etc going.

I am working now on a very large project and sometimes I wish that Visual
Studio had the feature to stop while loading, however I am glad it is not
there, mostly it is only a subject for bugs.

The latter just my thought,

Cor

 

[HONOREDANCESTOR]

Tom Shelton Answers:
Your question is difficult to give a straight answer to. You see,
events are really methods and are usually executed on the same thread
that they are raised on (this can be changed by using an async
delegate). So, your question depends on the architecture of you
application. Are you usingthreads? ThreadPool? Async delegates?
The system.windows.forms.timer is single threaded, but other timers
are not.

The events are be raised by some other dll, but I have a program that
calls the dll and so the events are in that program. I put a MSGBOX
in one of the events, and then ran the program, and I thought that the
program would stop at the MSGBOX until I hit OK. But thats not what
happened. Msgboxes kept coming up until the screen was full of them,
and then the program crashed. In other words, when the event stopped
at the msgbox, waiting for my input, the event was called again and
again, each time putting up more msgboxes. This suggests that I
really do have to worry about code interrupting other code.
The event is supposed to put some information from its arguments into
a buffer. I also want another routine that will empty buffer. But if
the event can interrupt itself, it should be able to interrupt the
routine as well. So maybe threads are needed. What do you think?