Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #495

Re: communicating sequential process and call processing threads

Show key headers only | View raw

On 03-08-2011 PM 03:22, itt ium wrote:
> Group,
> I am designing a call processing module loosely based on communicating
> sequential process (CSP).
> The call has well defined state machine. Most of the state changes are
> done when some message is
> received from some other network node. Currently the call process is
> devided in to multiple stages
> whenever process needs to wait for some event (like sending message to
> node/waiting for message from node with non-blocking sockets), a new
> stage is defined i.e socket read/write calls  are boundary for these
> stages.
>


> Whenever an event (like respone from some node) takes place,
> appropriate stage map is searched and processing starts from there.
> These events are received through some edge triggered mecahanism and a
> thread that read from the fd will try to cross as many stages as
> possible.
>
>   My question is
>
> 1 Is this model correct


In CSP models that I have seen, people keeps queue of requests at 
different stages (and not the map). Also make sure, mutexes are evenly 
distributed between stages. I will encourage you to read

http://pl.atyp.us/content/tech/servers.html

which touches some of these concepts.

> 2.Should I have processing threads per stage or global thread pool
> 3 I might like to define more stages in future. What can be guidelines
> for defining stages that are not based of read/write calls.
> 3. Google go language avoids need for state machine by defining
> goroutines (similar to co-routine). In my opinion, I can avoid
> coroutines/goroutine/fibers by state machine and non-blocking calls.
>

Threads are processing unit,  Idea of specialized thread may not be 
good. But if there is a thread pool, there should we some way for 
threads to find out current stage of transaction.

Co routines are difficult to debug. "Go" from google uses some of the 
CSP concept so it may be a good language for your problem. Also keep in 
mind that, in a google test, "go" performed badly, C++ was the best 
language.

> Because of the relevance I am posting the message to following groups.
>
> comp.unix.programmer
>
> comp.programming.threads
>

Avoid multiposting, use cross posting.

Naveen




> thanks
> ittium

Back to comp.programming.threads | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

communicating sequential process and call processing threads itt ium <ittium@gmail.com> - 2011-08-03 02:52 -0700
  Re: communicating sequential process and call processing threads "Naveen K. Kaushik" <naveenkumarkaushik@gmail.com> - 2011-08-09 10:57 +0530

csiph-web