Multi Threading

[jyohere]

Could anyone give me a detailed explanation about MultiThreading, Synchronistatio n and deadlock.....pl s Don't guide me to any site....as I have found it difficult to understand from other sites....i want to know the logic behind how threads are related to objects and why do they put wait,notify,not ifyall etc in the Object class....Please help with good detailed explanations... ..and this is my first request in this forum...so am expecting good replies from you all :-)

[JosAH]

Could anyone give me a detailed explanation about MultiThreading, Synchronistatio n and deadlock.....pl s Don't guide me to any site....as I have found it difficult to understand from other sites....i want to know the logic behind how threads are related to objects and why do they put wait,notify,not ifyall etc in the Object class....Please help with good detailed explanations... ..and this is my first request in this forum...so am expecting good replies from you all :-)

Every object has a little flag, a 'monitor'. Blocks of code that are synchronized
'obey' that monitor, i.e. when the flag is up the block of code waits until the
flag goes down again. Unsynchronized blocks of code don't do that, i.e. they
keep on running.

Suppose you and I both like cookies and we both spot a jar full of cookies.
We both run for the jar but we play it fair, i.e. we synchronize on the cookie jar.
One of us gets there first, raises the flag and the other one waits. When the
first person lowers that flag again (finished munching cookies) the flag is
lowered again and the other person get his turn.

But what to do if the jar gets empty? Suppose there's a third person that refills
the jar now and then. If the jar is empty then we wait, effectively lowering the
flag; the refiller comes to the jar, refills it and notifies all persons waiting for
the jar. The refiller could also pick a single waiting person at random. Then the
first scenario starts again: the first person to reach the jar raises the flag, eats
and lowers the flag again. Note that the refiller also obeys that flag.

If we don't play it fair, i.e. we don't synchronize on the jar object, we might end
up eating from the same cookie (yuck) or we might both think the jar isn't empty
yet (while it is) so we effectively eat thin air then. If the refiller doesn't play it fair
and doesn't notify at least one of us we stand there waiting 'till hell freezes over.

kind regards,

Jos

[jyohere]

Every object has a little flag, a 'monitor'. Blocks of code that are synchronized
'obey' that monitor, i.e. when the flag is up the block of code waits until the
flag goes down again. Unsynchronized blocks of code don't do that, i.e. they
keep on running.

Suppose you and I both like cookies and we both spot a jar full of cookies.
We both run for the jar but we play it fair, i.e. we synchronize on the cookie jar.
One of us gets there first, raises the flag and the other one waits. When the
first person lowers that flag again (finished munching cookies) the flag is
lowered again and the other person get his turn.

But what to do if the jar gets empty? Suppose there's a third person that refills
the jar now and then. If the jar is empty then we wait, effectively lowering the
flag; the refiller comes to the jar, refills it and notifies all persons waiting for
the jar. The refiller could also pick a single waiting person at random. Then the
first scenario starts again: the first person to reach the jar raises the flag, eats
and lowers the flag again. Note that the refiller also obeys that flag.

If we don't play it fair, i.e. we don't synchronize on the jar object, we might end
up eating from the same cookie (yuck) or we might both think the jar isn't empty
yet (while it is) so we effectively eat thin air then. If the refiller doesn't play it fair
and doesn't notify at least one of us we stand there waiting 'till hell freezes over.

kind regards,

Jos

Thanx that was quite interesting ....it would be great it you could explain all these with simple code.....

[JosAH]

Thanx that was quite interesting ....it would be great it you could explain all these with simple code.....

You first; when you get stuck feel free to post here again and we can probably
help you out.

kind regards,

Jos

[jyohere]

You first; when you get stuck feel free to post here again and we can probably
help you out.

kind regards,

Jos

You did not give an explanation why they put the threading methods in the Object class

[JosAH]

You did not give an explanation why they put the threading methods in the Object class

They didn't put threading methods in the Object class; they put the wait and
notify things in the Object class because you can synchronize, wait and notify
on *any* object. Now it's your turn.

kind regards,

Jos

[jyohere]

They didn't put threading methods in the Object class; they put the wait and
notify things in the Object class because you can synchronize, wait and notify
on *any* object. Now it's your turn.

kind regards,

Jos

Thank you:-)