🚀 go-pugleaf

Remy - Again - you are the master, over and over. Thankyou for the insight.

I am using BCB6 with the tthread app.

My problem is that  i think 2 threads maybe competing with each other in
non-thread safe code.
This tthread'd server listens on sockets, does recv(), send() on sockets,
open(), write(), read() on files.
One of the client programs freezes up occassionally transferring files, but
I can still communicate w/the server
on with other requests.

Does it sound resonable that one of these standard C library calls could not
be playing nicely with
multiple tthreads running at the same time? (all standard c calls are done
within the tthread object).

I was thinking of doing something like:

int TMyThread::myFileOpen(.......)
{
    int fd;

    EnterCriticalSection(&cs)
    fd = open(.....);
    LeaveCriticalSection(&cs)
   return fd;

}


Also the same for read/writing sockets, writing files,etc. This is just
about the only place I can think of that non-thread safe code might
come into play (Standard C library). All other code is VCL code.

Thanks again for your assistance - it is much appreciated.

CurtC



Remy Lebeau (TeamB) <gambit47@yahoo.com> wrote in message
news:3f3d64aa$2@newsgroups.borland.com...
>
> "CC" <Xcurtc@tmscorp.com> wrote in message
> news:3f3d5dfa$1@newsgroups.borland.com...
>
> > I was wondering if within a TTHread,
> > is it ok to use the winapi:
> >   EnterCriticalSection();
> >   LeaveCriticalSection();
> >   InitializeCriticalSection();
> >
> > Calls?
>
> Of course.  TThread simply wraps an API thread object.  Critical Sections
> are designed to be used with threads, particularly with multiple threads
> accessing them at the same time.
>
> > I have a tthread program, which I suspect is having
> > problems somewhere with multiple threads running
> > non-thread safe code.
>
> Always a source of potential problems.
>
> > I wanted to do something like:
> > EnterCriticalSection(...);
> > // read a file here, read from socket, close file, etc
> > LeaveCriticalSection();
>
> That is perfectly fine.
>
> > I would imaging the synchronize uses these calls.
>
> Only in BCB6.  In BB1-5, it does not use any API synchronization objects
at
> all.  It uses its own custom mechanism utilizing window messages instead.
>
> > The problems w/synchronize you cant pass arguments, etc to sync.
function.
>
> That is only partially true.  Although you cannot pass any parameters when
> calling Synchronize() itself, you can store the desired values into
separate
> variables which the synched method can then use once it is executed, ie:
>
>     AnsiString MyStr = "whatever";
>     int MyInt = 50;
>
>     ...
>     Synchronize(SomeMethod);
>     ...
>
>     void __fastcall TMyThread::SomeMethod()
>     {
>         // use MyStr and MyInt as needed
>     }
>
>
>
> Gambit
>
>