Threading question

  • Thread starter Thread starter kevinforbes
  • Start date Start date
K

kevinforbes

Hi All,

I inherited a multi-threaded windows serviece from a contractor where
every thread checks a shared dataset every 100ms for messages to act
on.

Is this the best way to communicate across threads? Is it possible to
push messages/call methods to individual threads by using delegates or
events?

What is the best practice for this situation?

Thank you,
KF
 
(e-mail address removed) wrote in @v33g2000cwv.googlegroups.com:
Hi All,

I inherited a multi-threaded windows serviece from a contractor where
every thread checks a shared dataset every 100ms for messages to act
on.
Click to expand...

FYI, datasets are not 100% threadsafe... they're only threadsafe for
read operations. I hope the contract has put some locking in for write
operations.
Is this the best way to communicate across threads? Is it possible to
push messages/call methods to individual threads by using delegates or
events?
Click to expand...

It really depends on your application. If the objects only need to
listen for incoming data, I would have used events.

However, if the objects need to process data in the mean time - perhaps
the dataset was not such a bad idea?

I really depends what you're doing.
 
(e-mail address removed) wrote in @v33g2000cwv.googlegroups.com:



FYI, datasets are not 100% threadsafe... they're only threadsafe for
read operations. I hope the contract has put some locking in for write
operations.


It really depends on your application. If the objects only need to
listen for incoming data, I would have used events.

However, if the objects need to process data in the mean time - perhaps
the dataset was not such a bad idea?

I really depends what you're doing.





- Show quoted text -
Click to expand...

Thank you for your response.

There are locks for writing, there were also locks for reading but I
removed those as they are not necessary according to MS.

Each thread acts on these dataset messages infrequently but also acts
on a number of telephony events which happen very often.

The reason i am considering changing the structure is that the service
seems to run pretty slowly under load for incoming dataset messages.
some will take 1 minute where they usually take 1 second.

thanks for your help,
KF
 
Thank you for your response.

There are locks for writing, there were also locks for reading but I
removed those as they are not necessary according to MS.

Each thread acts on these dataset messages infrequently but also acts
on a number of telephony events which happen very often.

The reason i am considering changing the structure is that the service
seems to run pretty slowly under load for incoming dataset messages.
some will take 1 minute where they usually take 1 second.

thanks for your help,
KF
Click to expand...


Also, I should note that this was all implemented using a
BackgroundWorker object, not raw threading. I'm not sure
backgroundworker is designed to be used in a class library (no UI) and
be available all the time, as opposed to a new backgroundworker object
being created for each long-running job. Anybody have some insight?

thanks,
KF
 
Also, I should note that this was all implemented using a
BackgroundWorker object, not raw threading. I'm not sure
backgroundworker is designed to be used in a class library (no UI) and
be available all the time, as opposed to a new backgroundworker object
being created for each long-running job. Anybody have some insight?

thanks,
KF
Click to expand...

Maybe he did it that way because that's what he could figure out.

Good luck.
Robin S.
 
(e-mail address removed) wrote in FYI, datasets are not 100% threadsafe... they're only threadsafe for
read operations. I hope the contract has put some locking in for write
operations.
Click to expand...

Hi,

Well, the documentation says, "This type is safe for multithreaded
read operations. You must synchronize any write operations."
Honestly, I'm not sure what that means exactly. I suspect it means
that it is safe for multiple readers only if there are no writers.
Otherwise, I would expect the documentation to read more like it does
for the Hashtable. If that's the case then I hope the contractor
synchronized reads as well since it sounded like there was at least
one simultaneous writer.

Brian
 
Hi,

Well, the documentation says, "This type is safe for multithreaded
read operations. You must synchronize any write operations."
Honestly, I'm not sure what that means exactly. I suspect it means
that it is safe for multiple readers only if there are no writers.
Otherwise, I would expect the documentation to read more like it does
for the Hashtable. If that's the case then I hope the contractor
synchronized reads as well since it sounded like there was at least
one simultaneous writer.

Brian
Click to expand...


That says to me that you don't have to lock the dataset for read
operations (no matter how many are reading) but you must lock if you
are writing to it (which i do).

Reads were locked but i removed that and have not had any (additional)
issues or improvements since.
 
Hi,

Well, the documentation says, "This type is safe for multithreaded
read operations. You must synchronize any write operations."
Honestly, I'm not sure what that means exactly. I suspect it means
that it is safe for multiple readers only if there are no writers.
Otherwise, I would expect the documentation to read more like it does
for the Hashtable. If that's the case then I hope the contractor
synchronized reads as well since it sounded like there was at least
one simultaneous writer.

Brian
Click to expand...


That says to me that you don't have to lock the dataset for read
operations (no matter how many are reading) but you must lock if you
are writing to it (which i do).

Reads were locked but i removed that and have not had any (additional)
issues or improvements since.
 
That says to me that you don't have to lock the dataset for read
operations (no matter how many are reading) but you must lock if you
are writing to it (which i do).
Click to expand...

Right, but the real question is can the readers occur simultaneously
with the writers? The documentation is not clear on that point. I
disassembled the DataSet and I'm not seeing any synchronization going
on. That says to me that although multiple readers may be thread-safe
by themselves they may not be thread-safe when writers are involved
even if the writers are synchronized.

Contrast the DataSet with the Hashtable. The Hashtable is thread-safe
for multiple readers and one writer. The documentation is very
explicit on that point. The Hashtable uses special lock-free
synchronization mechanisms to make it all work. If the DataSet truly
behaved like the Hashtable in regards to thread-safety then I would
expect the documentation to read like it does for the Hashtable, but
it doesn't.

All of this makes me think that a DataSet is only thread-safe for
readers when there are no writers. Of course, I can't be absolutely
sure of this.

Brian
 
Back
Top