Certain parts of thread not executing

Hi,

DWORD CALLBACK TForm1::ThreadFunc(void* P)
{
    int success;

    Log::LogWrite("HERE", 0);

    success = Listen();
    return 0;
}

I have this code.  The ThreadFunc is called right when the program starts up.  The Log::LogWrite opens up an ofstream, and writes to the end of the file.  Its not writing tho.  I know the problem isn't with this function because it works every where else in my application except in the ThreadFunc or any LogWrites within the Listen function.  I guess it might have something to do with my program trying to write to the log file, same time this thread is trying to write to the log file.  How would I go about getting the logs to write without any major application slowdown.  Thanks!
LVL 2
corduroy9Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

AxterCommented:
When you write to the file, do a flush.

The problem could be that it's still inside the cache
George TokasCommented:
Declare a global bool lets say fileopened...
When some thread or function try to open the file first check that flag..
Lets try it in your thread function:

DWORD CALLBACK TForm1::ThreadFunc(void* P)
{
    int success;
    while(fileopened){//the file is opened by another function or thread
      Application->ProcessMessages();//VITAL!!!!!!!!!!! for the application not hangs
    }
    fileopened = true;//Set the flag.
    Log::LogWrite("HERE", 0);//suppose this is the write function somewere in the
                                           //code
    fileopened = false;//reset the flag
   }
   
    success = Listen();
    return 0;
}

The set and reset of the flag must be made on every place you are accessing the file.

gtokas.
P.S. The same can be done and with Synchronize function but I'm a fun of flags.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
AxterCommented:
>>P.S. The same can be done and with Synchronize function but I'm a fun of flags.

Flags that are not syncrhronize are not a good idea, and will lead to bugs.

Any global variable that may be modified by multiple threads should be synchronized.

Check out the following wrapper class for an easy method to synchronize your variables:
http://code.axter.com/sync_ptr.h

The sync_ptr class is a smart pointer class with synchronization logic built into the pointer operator.

It automatically locks the variable when access, and unlocks it when complete.
Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

George TokasCommented:
Sorry my friend Axter but I have to disagree here...
A good designed "lock" like part of code using flags I think it is better debugable...
Lets not forget that there WAS times when we didn't had multitasking and multithreading and had to use interupt vectors and code there...
Maybe I am a relic of an (VERY) old era...:-) (Z80)

gtokas.
AxterCommented:
>>A good designed "lock" like part of code using flags I think it is better debugable...

How will a flag work if you have two threads modifying it at the same time?

You can have two threads waiting on the flag to be set to false, and when the flag is set to false, both threads can then simultaneously pass the while(fileopened) condition statement, and then you'll have both threads writing to the file at the same time.

A flag with out synchronization will lead to a buggy program that will have interment ant bugs, that are hard to track down.

If it was that easy to use flags in a multithread application, then there would be no need for mutex or critical-section API's
George TokasCommented:
>>both threads can then simultaneously pass the while(fileopened)
Don't think so... I think you forget the quantum of the thread...
One of the threads in the first in line quantum will set fileopened and the others will wait...
Thats my oppinion of course judging at things on some books I read...

gtokas.
P.S. Nice to have exchange of oppinions with you Axter...:-) It's been a long time since we had...:-)
AxterCommented:
>>One of the threads in the first in line quantum will set fileopened and the others will wait...
That's right.
But if you have two threads waiting, then when the first thread sets fileopened to false, you'll then have the other two threads racing to set fileopened to true. (Race condition).
At that point, both threads can simulaneously pass the while() condition statement, and both threads will try to set fileopened to true.
In which case, both threads will be writing to the file.

>>P.S. Nice to have exchange of oppinions with you Axter...:-) It's been a long time since we had...:-)
Same here.
Why did you stop participating in the C++ topic area?
George TokasCommented:
>>But if you have two threads waiting, then when the first thread sets fileopened to false, you'll then have >>the other two threads racing to set fileopened to true. (Race condition).
Sure... But depending on the priority of the quantum one of them will pass the while statement and will set the flag depending of course on the speed of the machine... But in a P4 the quantum is enough to pass the while (with proccessmessages which is expanded to a very large code if we examine it at debug windows) and set the flag... So the other thread will wait again...
Anyway to prove my point:
C++Builder 4 Unleashed on chapter 4 deals with threads and mutexes...
I have the code uploaded at my homepage at:
http://users.forthnet.gr/the/jtokas/test
there is a file named ch5.zip.
There is a subdirectory called Thread1...
its an access to canvas from a thread with GetDC() and ReleaseDC().
If we try to use GetDC() from another thread when this one had control will result to an access violation...
if we modify the code a bit with a flag we can test our points...

>>Why did you stop participating in the C++ topic area?
In standard c++ and windows API's I'm not that good as you there...:-)
But on BCB I'm using since Version 1. Went through hell till I finally made it to work as robust as I wanted with DirectX... I also hate MS tools from their C compiler (imagine the time passed)... Visual Basic sucks at versions of studio before the latest one... And also ALL the questions I had you guys at c++ allready had posted sollutions...:-)
The truth is that I'm accessing internet from work and I avoided to have access and at home because I have 2 children not very old (9 and 5) and if I need my time with them not with the net...:-)
So the time I have is limited to check out all the places I can participate.
George TokasCommented:
btw...My next project will be deal with "smart houses"...
Interested on some point of cooperation??
AxterCommented:
>>I have 2 children not very old (9 and 5) and if I need my time with them not with the net...:-)

Very good point.
Kent OlsenDBACommented:
Hi Axter, gtokas,

It would seem that BCC has already solved this issue.  :)

Simply create the threads in a suspended state, open the log file, and then Resume() the thread.


Kent
AxterCommented:
>>It would seem that BCC has already solved this issue.  :)
>>Simply create the threads in a suspended state, open the log file, and then Resume() the thread.

What if the log file is already open?
What if another thread is already writing to the file?

IMHO, this would not solve this issue.
George TokasCommented:
I have to made a point a bit clear.
Corduroy9 used the example of the thread from ch5.zip I uploaded...
I uploaded it for him (and for anyone else who want it) to take a first taste on how threads and mutexes works...
Of course TThread object is NOT there...
But to post the way TThread works and the synchronize methods needs a lot of space here... Thats the main reason why I choose to use a flag inside the thread to check... The other reason is that I'm a relic of the Z80 era and assembly....:-)

BUT I have a question for you Corduroy9:
Did ALL those posts between me, Axter and Kdo helped you to understand anything more than your original question??
If not feel free to post your questions here...:-)

gtokas.
George TokasCommented:
One more thing...
I have to agree with Axter's point of view when the application is multithreaded and the machine is using a multi(double) core cpu... The new ones from Intel and AMD...
And this only if the OS allow it to be done...

gtokas.
Kent OlsenDBACommented:

Hi Axter,

I guess that I wasn't very clear.  Sorry.


>What if the log file is already open?
>What if another thread is already writing to the file?

The log file is under the control of the main thread.  It is opened and closed from there.  Ideally, it is also only read/written from there as I/O from/to it should be syncronized into the main thread.  Threads created by the application do not open/close the log file.

My suggestion to start the thread suspended is to accomodate application start up.  The main thread needs time to complete its initialization and open the log file before any secondary thread tries to access it.  As long as the main thread opens the log file before the other threads try to access it, there's no need to check the log file status for every access.

I've used that technique quite a bit.  It works very well.
Kent



George TokasCommented:
Thats and my point of view Kent....:-)
I just use a flag...
>>I've used that technique quite a bit.  It works very well
Me too....:-)

gtokas.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Editors IDEs

From novice to tech pro — start learning today.