[prev in list] [next in list] [prev in thread] [next in thread] 

List:       osdlcluster
Subject:    RE: [Osdlcluster] "Event Service Interface Protocol"betweentheevent
From:       "Zhang, Sonic" <sonic.zhang () intel ! com>
Date:       2004-02-11 4:21:31
Message-ID: 37FBBA5F3A361C41AB7CE44558C3448E5A30AF () PDSMSX403 ! ccr ! corp ! intel ! com
[Download RAW message or body]

Hi Steven,

	I found a solution to deal with the multithread cases.

	I think the final objective of the OSDL event service project is to inject it into \
the Linux kernel as a module. So, we can drop down our criteria on the response delay \
of the daemon prototype implementation, provided this drop doesn't affect the kernel \
implementation.

	My solution is to block each synchronous request from a user thread till the \
operation is completed by the event service, while asynchronous reply is still \
differentiated by variable async_id.

	In daemon prototype implementation, the block is assured by the pthread_mutex on the \
socket-based request-reply procedure in the event library. This may cause second-long \
response delay in multi-thread application. But it is acceptable for a prototype.

	In the kernel implementation, the event library completes the request through the \
system call. A user thread can invoke a system call before the others return from \
their system calls. No block is necessary in the event library side.

	In this way, we keep the architecture of different implementations as similar as \
possible. This can minimize our workload to port the user space prototype to the \
kernel module. Please see my new update.

	Regards


*********************************************
Sonic Zhang
Software Engineer
Intel China Software Lab
Tel: (086)021-52574545-1667
iNet: 752-1667
********************************************* 

-----Original Message-----
From: Steven Dake [mailto:sdake@mvista.com] 
Sent: 2004Äê2Ô 11ÈÕ 2:15
To: Zhang, Sonic
Cc: scd@broked.org; OSDL Cluster; Mark Haverkamp
Subject: RE: [Osdlcluster] "Event Service Interface Protocol"betweentheevent library \
and the event service is added.

On Tue, 2004-02-10 at 01:37, Zhang, Sonic wrote:
> Hi Steven,
> 
> 	"Simultaneous" here doesn't mean that 2 threads operate one file descriptor at the \
> same time. The read or write operations are of course under the protection of the \
> pthread_mutex.  
> 	It may costs some seconds for the event service to complete a request and return \
> the results. Do you think it is good to block the other threads from sending their \
> request packets before the former one receives the reply packet? This may cause \
> long time response delay in multi-thread user application. Is it acceptable? 
> 	If so, I will remove the operation_id and change the reply head definition.
> 
> 	In kernel implementation, system call is planned to complete the operations. Do \
> you think we also have to block different threads from doing the system call \
> simultaneously? 
> 	Thanks.
> 

The blocking is a tough issue when considering multiple threads..  I had
not considered it.  Perhaps we can look at the results and see if we
require further improvements once we have a start implementation?

thanks
-steve
> 
> *********************************************
> Sonic Zhang
> Software Engineer
> Intel China Software Lab
> Tel: (086)021-52574545-1667
> iNet: 752-1667
> ********************************************* 
> 
> -----Original Message-----
> From: Steven Dake [mailto:scd@broked.org] 
> Sent: 2004Äê2Ô 10ÈÕ 14:28
> To: Zhang, Sonic
> Cc: Mark Haverkamp; OSDL Cluster
> Subject: RE: [Osdlcluster] "Event Service Interface Protocol" betweentheevent \
> library and the event service is added. 
> On Mon, 2004-02-09 at 21:09, Zhang, Sonic wrote:
> > Hi Mark,
> > 
> > 	Answer your questions.
> > 
> > 1. Adding a field to indicate the size of each packet is a good
> > suggestion, because the UNIX socket doesn't support SOCK_SEQPACKET
> > protocol. Size field will make the implementation easier via SOCK_STREAM
> > protocol.
> > 
> > 2. Yes, the operation_id is used to associate the reply packet with the
> > request packet. One reason is that the request and reply are
> > asynchronous. They may be out of order. The other reason is that if
> > there are more than 2 threads in the use application that do the request
> > simultaneously, they can be differentiated by the request id. 
> > 
> I strongly recommend against using this model for threading..  Allowing
> two processes at the same time to operate on a file descriptor is asking
> for trouble and seriously complicates the design.  pthread_mutex can
> protect these critical sections (ie: the access of the filedescriptor
> with read/write/send/recv).  Then there is no guess work about matching
> one thread's request to a different dispatch's response.  The rare case
> of async notifications can include the complexity as necessary.
> 
> > 3. The request packet refers to the packet received by event service
> > from the event library. And the reply packet only refers to the packet
> > return from the event service to the event library. So, there is no
> > confusion.
> > 
> > 4. You are correct. I add the library initialization operation into the
> > document.
> > 
> > 
> > 	Please see the updated document.
> > 
> > 	Thanks.
> > 
> > 
> > *********************************************
> > Sonic Zhang
> > Software Engineer
> > Intel China Software Lab
> > Tel: (086)021-52574545-1667
> > iNet: 752-1667
> > ********************************************* 
> > 
> > 
> > 
> > _______________________________________________
> > Osdlcluster mailing list
> > Osdlcluster@lists.osdl.org
> > http://lists.osdl.org/mailman/listinfo/osdlcluster
> 
> 
> _______________________________________________
> Osdlcluster mailing list
> Osdlcluster@lists.osdl.org
> http://lists.osdl.org/mailman/listinfo/osdlcluster
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]