Multithreading: implementing the event based pattern

re: Multithreading: implementing the event based pattern

luisabreu — Fri, 23 Oct 2009 18:15:40 GMT

Sorry for the late reply, but i've been a little busy.

please disregard my last comment because i didn't understand the question...

I'm still not sure if you want to 1.) stop the current processing when the a new event arrives or 2.) you don't want to stop the current processing when another event arrives.

if you want 2, then you can use a collection where you have producers and consumers (ie, you can have several threads putting stuff there and others removing). I think I've written a post on it a long time ago...

if it's 2, then you'll have to keep looking for new objects in the queue. when it's there you'll have to stop the current action (probably use some sort of compensation for cancelling it before starting the new one?)

re: Multithreading: implementing the event based pattern

Irfan — Wed, 21 Oct 2009 12:19:12 GMT

Didn't get your point. Can you elaborate it a bit? Thanks

re: Multithreading: implementing the event based pattern

luisabreu — Wed, 21 Oct 2009 10:21:36 GMT

Wouldn't you be better by using some sort of compensation mechanism instead of enforcing "real time" handling of an action?

re: Multithreading: implementing the event based pattern

Irfan — Wed, 21 Oct 2009 09:11:39 GMT

Yes, if the thread that have registered events of the asyncmethod is busy in executing business actions of an event and meanwhile another event is raised from the asyncmethod, that stops the previous event and starts the new event business execution.

So if I don't use this pattern then how to achieve event driven programming in a multi-threaded application?

re: Multithreading: implementing the event based pattern

luisabreu — Wed, 21 Oct 2009 08:32:21 GMT

I'd say no. the event pattern should be used essentially in UI scenarios, where you need to make sure that the callback method is executed back in the some thread which started the async call. it looks like this is not the scenario you've got, so I'd say you won't be gaining much from using it.

btw, i'm still not sure in what's the problem you're facing when receiving a new event. are you saying that you can't just have another thread do something if currently there's a business action going on as a result of a previous event?

re: Multithreading: implementing the event based pattern

Irfan — Wed, 21 Oct 2009 06:57:41 GMT

I need to develop a network application that consists of two modules. One need to handle the clients, i.e., send/receive requests/data from clients and the other module need to handle the business logic for different requests. Now I want to execute the clients management module in a separate thread and generate events in response of clients requests. The other module that implements the business logic will subscribe to these events and perform corresponding actions in response to the events raised. Now the problem is if an event is raised from client management module and business logic layer is executing the request. Mean while if another event is raised, current event is interrupted and the new event starts executing. So I need a solution to avoid this problem. One way is to implement my own queue management system that queues events when raised and forward to business layer when it becomes idle. So my question is should I use event based pattern in this scenario or it is not suitable in this case? If yes i should use, then what about the problem i have mentioned, how to handle it?

re: Multithreading: implementing the event based pattern

luisabreu — Tue, 20 Oct 2009 09:48:52 GMT

Hello.

I'm not following you. can you be a lilttle more specific please? thanks.

re: Multithreading: implementing the event based pattern

Irfan — Tue, 20 Oct 2009 08:13:40 GMT

Can you explain how to handle the scenario where the callbacks generation speed of the async event class is greater than the consuming thread (console based application where no queuing mechanism is implemented by default). Currently I am locking the consuming thread using lock(this){ event handler } to solve this issue. Is this a valid approach? Or the event based asynchronous model is not valid approach in this scenario?

Regards

Для тестирования нового вэб-проекта, требуются :

GreenCard — Wed, 01 Jul 2009 16:27:55 GMT

Для тестирования нового большого вэб-проекта,и выявления багов,набирается тест-группа, 50 человек.

Для участия в тестировании необхдим персональный компьютер подключенный к быстрому

интернету.

Каждому тестировщику будет посланы задачи и суть теста.

Тестирование не требует особых знаний компьютера или програмирования!

На компютере не будет устанавливатся какая либо программа, и нету использования вашего трафика.

Тестирование в свободное время.

Участие в проекте допустимо лицам выше 16-лет.

Условия участия, оплата, инструктаж, и контакты будут посланы по востребованию.

Для участия необходимы программы : Skype/Скайп или Айсикью/ ICQ .

Местоположение тестировщиков - значения не имеет.

Заявки посылать на эл.адрес webp2010@gmail.com

Multithreading: updating the code to support multiple asynchronous executions of one method

ASPInsiders — Sat, 20 Jun 2009 14:35:56 GMT

In the previous posts, we’ve seen how to implement the asynchronous event based pattern and how to support

Multithreading: updating the code to support multiple asynchronous executions of one method

LA.NET [EN] — Sat, 20 Jun 2009 14:26:44 GMT

In the previous posts, we’ve seen how to implement the asynchronous event based pattern and how to support

Multithreading: implementing the event based pattern - LA.NET [EN]

9eFish — Thu, 18 Jun 2009 02:25:20 GMT

9efish.感谢你的文章 - Trackback from 9eFish