Hello again, and thank you for your help.  I will attempt to describe 
our application in more detail.

We have three threads: thread #1 transmits packets, thread #2 receives
packets,
and thread #3 transmits packets.  For the purpose of this discussion,
(and for
all of our testing thus far), we only consider threads #1 and #2.
Currently, 
both threads (#1 and #2) use the SAME LPADAPTER object, but each thread
has 
its own LPPACKET object.

The basic flow is this:  Thread #1 transmits a packet and then waits for
a Receive 
Event.  Thread #2 listens for packets, eventually receives a packet,
sets the Receive Event, 
and then continues listening for packets.  Thread #1 resets the Receive
Event, and transmits a packet...
This process repeats itself.  I hope that the application will not
overload the 
adapter, because thread #1 will not transmit another packet until it has
received a 
response to the previous packet via thread #2.  We find in practice,
however,
that occasionally there is a dropped packet: either thread #1 does not
successfully transmit, or thread #2 does not successfully receive.  The
functions 
PacketSendPacket in thread #1, and PacketReceivePacket in thread #2 are
protected 
by mutex objects like so:

//thread #1
WaitForSingleObject(hIOMutex, INFINITE);
PacketSendPacket(lpAdapter, lpTxPacket, TRUE);
ReleaseMutex(hIOMutex);

//thread #2
WaitForSingleObject(hIOMutex, INFINITE);
rtnVal = PacketReceivePacket(lpAdapter, lpRxPacket, TRUE);
ReleaseMutex(hIOMutex);

The one and only adapter object is set up in the following way:

PacketSetReadTimeout(lpAdapter, -1);  //return immediately to prevent
deadlocking/delay       
PacketSetHwFilter(lpAdapter, NDIS_PACKET_TYPE_PROMISCUOUS);
//promiscuous mode              
PacketSetBuff(lpAdapter, 512000);  //set a 512K buffer in the driver
PacketSetNumWrites(lpAdapter, 1);

There is one other reference to the lpAdapter object in thread #1 that
is not
protected by a mutex, but it should not change the adapter:

if( lpAdapter == NULL || lpTxPacket == NULL || lpRxPacket == NULL )

I hope that this was clear enough to explain our application, and
concise enough
so that you do not resent the length of the explanation!  For the time
being, I will
take your advise and open separate adapter objects for the separate
threads.  Next,
if necessary, I will protect the currently unprotected line with a
mutex.  I will
post the results of this, regardless of success or failure.  If there is
anything more
that needs an explanation, I will be happy to go into even greater
detail.  
I appreciate your time and help in this matter very much!

Errett


-----Original Message-----
From: Loris Degioanni [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 02, 2002 4:12 AM
To: [EMAIL PROTECTED]
Subject: Re: [WinPcap-users] Multithreaded application


Can you provide more details about your program? Do you use a thread to
read
and another to write? Do the two threads read or write at the same time
from
the same device descriptor? Do you perform the operations on different
descriptors?
The latter case is advisable, because having two thread accessing the
same
descriptor can bring (like for a file) to inconsistencies. I used
occasionally this configuration and I didn't notice packet loss.

Loris


> Hello,
>
> My company is developing a simple proprietary protocol to communicate
> between ethernet ports.  We are using the ethernet medium, and the
WinPcap
> v2.3 library, to communicate reads, writes, and interrupts.  A PC
(Windows
> 2000) with an ethernet card serves as the master, and a development
board
> serves as the slave.  In our design, we have two different threads
that
send
> packets from the PC to the board, and one thread dedicated to
receiving
> packets from the board.  I have read the FAQ which states that there
are
> problems with multiprocessor machines.  After some testing, it seems
that
a
> single-threaded application can send and receive packets without
dropping
> any.  However, our multi-threaded application will occasionally drop
some.
> There are no apparent deadlock issues in our app.  My question is if
the
> same issues with multiprocessor machines extend to multithreaded
> applications?  Are there any tips that you have for using the WinPcap
> libraries in multithreaded applications?
>
> Thank you in advance for your help, and great job with WinPcap - we
have
> found it very useful!
>
> Errett
>
>
> _________________________________________________________________
> Join the world's largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>
>


Reply via email to