Hi

I have recently noticed lockups in a Windows Service of mine after
changing code to WriteFile() directly to client named pipes instead of
routing all messages via a client manager thread. The lockups appears
to be in kernel code (debugger claims it's sprintf etc and i can't see
any of my code on the stack) and iternal.

Normally the code works much faster but when there is tens of threads
writing at the same time it sometimes seems like the pipe blocks.

A few questions about pipes:
1. Is it safe to assume that WriteFile() will allow only one of the
threads access to the pipe until the whole message is sent?
In other words, should i spend time syncronizing myself?
(Is the same true also for byte mode pipes?)

2. Is there any way to find out how many messages or bytes are
still in a pipes outbuffer? This could be useful so some threads
could opt to sleep or even skip sending of noncritical messages
for a while.

3. Are there any other restrictions than the 64 kB message limitation
on named pipes?

Also, are WritePrivateProfileString() writes syncronized or is it possible
that multithreaded updates of same file sections can cause problems?
I use INI files for some Release version debugging.

- Sten

take a closer look at these functions



CallNamedPipe
ConnectNamedPipe
CreateNamedPipe
CreatePipe
DisconnectNamedPipe
GetNamedPipeHandleState
GetNamedPipeInfo -> information about the output buffer
PeekNamedPipe
SetNamedPipeHandleState
TransactNamedPipe
WaitNamedPipe -> blocks until pipe instance available to connect


It is possible to create multible instances of a named pipe. I think you
should try to do so in order to avoid more than one thread writting to
the same pipe at one time

hope this helps

"Robert Wierschke" <wierob@gmx.de> wrote in message
news:dcpsvb$34i$00$1@news.t-online.com...
I have used most of those and think i have read the description of all.
They doesn't seem to go into this type of detail.



1. tens or hundreds of remote clients connecting (accepted by WaitNamedPipe)
2. one "client manager" thread for each operator (ImpersonateNamedPipe() +
GetUserName() that connects. It takes care of requests from all of the
operators
clients and also broadcasts some messages.
3. the clients may request services from "client manager". The one service
relating
to my issue is "start operationpname,parameters" to which it responds
by
starting separate operation threads (identified by a mailslot with an
atomic name).
4. several of these operations often want to send (change) messages to
several
clients (users of same data entity) at the same time (especially on SMP
systems).
In addition they also add entries to a file, syncronized by an critical
section.
5. old solution:
construct and send message to "client manager" to ask it to forward
it to
all clients by traversing a linked list of structures to find out
which pipes should
be targeted. This was slow and had problems relating to mailslot
flooding and
slow responsetime and also distrurbed other operations needing
access to
internal resources protected by critical sections.
new solution:
"client manager" (and other "operations"-- the primary reason for
change)
subscribe to change messages for a specific data set.
Then a list of handles to pipes to clients is simply stepped trough
(under control
of a critical section) and WriteFile() is called. Thus the
"operations" are syncronized
among themselves but the question is, do i have to use the same
critical section also
in the "client manager" thread just because it uses the same handle
to pipe?

Anyone with better ideas?

Anyway Robert, thanks for you attempt

- Sten

better idea use sockets. pipes are interprocess comunication method,
designed for communication between two (so they might not very usefull
for tens or hundreds) processes


client manager == server ???

if it is a thread why use pipes; pipes are used for communication
between processes, so if the threads belong to the same process use a
shared varaible and a critical section.



again I think you should use one server (lunching worker threads for
doing the requested work) and clients connected via sockets


mybe you should use an event objct here: setting the event signaled by
the worker thread in order to inform the clients about the changing or
trigger an update request by the clients


If they all accessing the same file, use a mutex or appropriate
arguments to CreateFile to allowl only on access to the file at a time

"Robert Wierschke" <wierob@gmx.de> wrote in message
news:dcsoii$iuu$01$1@news.t-online.com...
Say that to among others Microsoft (Regedt32, Eventvwr, MMC plugins).
Sockets are fine as such but
a) one would need to invent a way to specify message size (header)
b) received message parts need to be concatenated "manually"
c) one would need to perform secure authentication oneselves
d) impersonation of user can be difficult


communications.
Also, shared variables doesn't automatically include queing so i'll stick
with
mailslots for intra-process messaging.

also have the same problem with them.



that the "client manager" thread doesn't use that file at all so i wouldn't
like to have it distrurbing the file use by syncronizing with the
operations.

- Sten