Locking threads

Don't store the object as an instance field. Deserialize it to a
local variable and pass it along as a parameter to the other functions
(deserialize, process, rebroardcast, etc.)

You don't want to add extra locking to force your system to only
handle one object at a time 'cause that would be very poor concurrency
and could cause a backlog of data to be processed.

You may also want to look into using multiple threads for the
broadcast to other clients.

HTH,

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking Mid/Sr. .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Tue, 13 Feb 2007 04:20:03 -0000, "PokerMan" <no****@pokercat.co.uk>
wrote:

>Hi

I have a server listening and when it receives an object deserilalises it.
Reads it, does whatever it needs, reserialises it and then broadcasts it to
clients (depending on what object was sent, found when it deseriliased it).

The problem is this:

1) Server receives object, deserialises
2) reads and serilaises again
3) go into broadcast loop to all clients. <-------but while doing this
receives a new object and deserialises it!

My comment in point 3 i believe is what is occurring. How can i protect such
a situation. This is what i believe is the solution but i would like someone
to either confirm or point me the right way if i am wrong.

i do this on the broadcast now:

lock(staticObject)
{
DoBroadCast(objToSend);
}

My thinking is that by doing that:

1) it locks any other thread from altering my objToSend object until
DoBroadcast is done with it.
2) All new objects sent to server will wait until they can access the obj so
they can deseriliase into it.
3) Broadcast finishes, releases lock, andnext object can now be deserialised
and used by server.

Am i right in my logic of how it will react to that lock?

Thanks

Hi Sam

Thanks for replying, but firstly in answer to my post, regardless if its the
best way, i am aware of performance hit, is my thinking as to the way the
lock would effect my programme right?

I do serialiase to a local object. The problem is that my asynchronous
action that fills a data stream from the data received has to be a instance
field. It is this that i believe is getting changed before my handling code
can complete. It passes that var into the handling code, that then
deserialises to a local object.

So do you think my best move is to do my broadcast on a new thread and lock
that thread? To be honest i am not sure why my object seems to be getting
changed during a broadcast, or during a serilsation. My code does seem to
handle it, however due to the issues and the 'symptoms' all pointing to that
problem i felt locks were needed. If that solves it then i know for sure
this is the cause. Then i will go through removing locks and looking at
better faster solutions to the same issue. (For example i can serialise the
data once, then send to all clients, at present i serilalise and send
everytime ;) ).

Look forward to all suggestiongs or thoughts. Importantly i'd like to know
if my thinking on original post was right, since no disagreement i will
assume i am right?
"Samuel R. Neff" <sa********@nomail.comwrote in message
news:1r********************************@4ax.com...

>
Don't store the object as an instance field. Deserialize it to a
local variable and pass it along as a parameter to the other functions
(deserialize, process, rebroardcast, etc.)

You don't want to add extra locking to force your system to only
handle one object at a time 'cause that would be very poor concurrency
and could cause a backlog of data to be processed.

You may also want to look into using multiple threads for the
broadcast to other clients.

HTH,

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking Mid/Sr. .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Tue, 13 Feb 2007 04:20:03 -0000, "PokerMan" <no****@pokercat.co.uk>
wrote:

>>Hi

I have a server listening and when it receives an object deserilalises it.
Reads it, does whatever it needs, reserialises it and then broadcasts it
to
clients (depending on what object was sent, found when it deseriliased
it).

The problem is this:

1) Server receives object, deserialises
2) reads and serilaises again
3) go into broadcast loop to all clients. <-------but while doing this
receives a new object and deserialises it!

My comment in point 3 i believe is what is occurring. How can i protect
such
a situation. This is what i believe is the solution but i would like
someone
to either confirm or point me the right way if i am wrong.

i do this on the broadcast now:

lock(staticObject)
{
DoBroadCast(objToSend);
}

My thinking is that by doing that:

1) it locks any other thread from altering my objToSend object until
DoBroadcast is done with it.
2) All new objects sent to server will wait until they can access the obj
so
they can deseriliase into it.
3) Broadcast finishes, releases lock, andnext object can now be
deserialised
and used by server.

Am i right in my logic of how it will react to that lock?

Thanks

PokerMan <no****@pokercat.co.ukwrote:

So do you think my best move is to do my broadcast on a new thread and lock
that thread? To be honest i am not sure why my object seems to be getting
changed during a broadcast, or during a serilsation. My code does seem to
handle it, however due to the issues and the 'symptoms' all pointing to that
problem i felt locks were needed.

Thread safety is a delicate matter, and can't be properly solved by
adding in locks until everything appears to work.

I think you have some mistaken beliefs about what locking does, given
this post and your original one. You don't lock a thread - you acquire
a lock on the monitor associated with an object. That won't stop
anything else from changing the contents of that object - it will only
stop other threads from acquiring the same monitor.

Threading is too big a topic to go into much detail on in a newsgroup
post, but you might want to have a look at my threading article for
more discussion:

http://pobox.com/~skeet/csharp/threads

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