A crazy noob has just created a new but uncompleted tutorial and put it on the Wiki, it's your objective to clean it and refine it. So others members can use it and not get confused.

Objectives:

- Orthography
- Typos
- Expressions

START
OPTIONS
CREDITS
EXIT

Published by: UBISOFT™         A game by: AMCerasoli™

You don't explain well why you should check for the is_ready flag, you skip explaining lock_cond, there were some typo's and I still can't log into the wiki^[1].
Oh yeah, and good job Personally I'd like to squeeze out the C++ bits, and mash it all into a smooth Allegro example. It's gonna be loovely. </ tvchefimpersonation>

When the Wiki read your sign, said NO WAY BODY!

Sarting out sarting?

Oh, and as for the C++: learn to use initialization lists.

Oh, thanks gnolam, I didn't know anything about initialization list, well I think was obvious hohohoho.

Anyway I have changed it:

I think now it's fine.

and what for it's the {} at the end now?

@weapon_S I can't manage to explain better the example, how would you explain it? write it here, and I'll post it. Only that part that you said.

{"name":"604195","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/9\/99e8f31cf663c1df6d02aa0e3ba52274.png","w":343,"h":623,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/9\/99e8f31cf663c1df6d02aa0e3ba52274"}

In that loose {}, you should be checking the return values of al_create_mutex() and al_create_cond(), if they failed to be created, then either throwing an exception, or set a value to mark the class as bad.

Or have a separate init method that can return a failure.

Some things I don't understand, some things I think should be improved, but don't know how, and some things I know are wrong but-what-the-hey are marked with triple question marks \???
I also think this should be either god-grieving C++ or satanlicious C: not a mix.
You know what would be kinky? If the parent thread used a (second) condition to start the two child threads.
<insert worst profanity /> It seems file upload I broken too. (But only for me of course. And, yes, I know about the new backwards editing procedure.)

Didn't I read somewhere or other today about the evils that beset video bitmaps and threads?

It should be in C, since Allegro is a C library.

You shouldn't touch a GL/DX context from more than one thread at a time. Bad things can, and WILL happen.

Somebody willing to post my blerp of text to the wiki and maybe give it a critical look?
(Shouldn't this topic b moved out of the depot?)

I'll update the tut when I get the time. all this thing about threads it's incredible.

Edit:
I have uploaded the weapon_S tut.

Why are you using those // and _ _ like if you were writting on allegro.cc? On the Wiki that doesn't work.

ok we have some questions:

1 - A thread is like a program running separately. Separately means you have no idea how far it has run, and neither do they know about each others globals?.

2 -thread_1 is allocated. Don't forget to deallocate it afterwards. Shouldn't you check it's its value?

Neither al_start_thread and al_create_thread returns a value so how could I check it?

3 - The thread will be running the function Func_thread and getting the pointer *data as its argument when it starts. (Or only after it started it head hurts)

To be honest I don't understand the question.

4 - al_wait_cond takes a locked mutex as an argument???

On entering this function, mutex must be locked by the calling thread. The function will atomically release mutex and block on cond. That is what the manual says, I don't know if you was referring to another thing.

5 - In what order are you discussing the file? In what order was I discussing the file? I already discussed this???

When I said "Everything until here should be already clear" I was referring to the rest of the code the initialization of allegro, mouse etc, I guess I can remove it, though.

Here:

al_lock_mutex(data.mutex);
   while (!data.ready){
 
      al_wait_cond(data.cond, data.mutex);
 
   }
   al_unlock_mutex(data.mutex);

Instead of a while can't we use an if?

PS: the

<code></code>

tags shows the letters too small, can't be increased?

Read al_create_thread again - it returns an ALLEGRO_THREAD*, 0 on failure.

No, because al_wait_cond may return for reasons other than the condition becoming true. That's why you need to keep checking the variable.

I thought // , ** and __ were called "wiki-markup"

1. Woops, my bad. I was confused for a second. It is a very bad idea to use globals to communicate between threads, it is however not impossible.

2. What he ^ said.

3. When it starts. (?) I can't remember asking that. Should be obvious. Or you could say that when it starts and after it starts are indistinguishable, because in neither cases any code has run.

4. Yes, I was referring to the manual. So, maybe expand that to "a mutex which is locked". I think it is very vital to understand such details.

5. Haven't looked yet at the new version. Removal sounds good.

You can pass in an argument to al_create_thread just like you can with pthreads.

I read somewhere that threads shouldn't be called "parents" or "child" I can't remember where, though. In the tutorial we're using those terms, should I keep it?.

Edit:

I have another question... why is useful a cond? if for example I have

al_lock_mutex(data.mutex);
while(!data.ready){}
al_unlock_mutex(data.mutex);

and that's it? that would wait until ready is... ready.

That would wait forever. (Variable is locked.)

It would never release the mutex. It would sit in there forever blocking the other threads that want the mutex in order to change the variable.

When you wait on a condition variable, it essentially goes like:

1. lock mutex

2. check variable, if ready go to step 6

3. unlock mutex

4. wait on condition

5. repeat

6. unlock mutex

I had to think for a sec before I saw that was correct. Slightly more elaborate steps written out. (You call this a 'diagram'? )

1. lock mutex

2. check variable, if ready go to step 6

3. al_wait_cond:

   • unlock mutex

   • wait on condition

   • lock mutex

4. goto 2

5. unlock mutex

Ohhhh it's true... , know I think I understand it very well... al_wait_cond() unlock the mutex and block on the cond (the same that the manua says, I couldn't understand it the first time I read it ). I'm thinking in many threads using the same data, it's a good idea having just one cond and many flag to check if all the threads have done their job? something like:

al_lock_mutex(data.mutex);
while(!data.flag1 || !data.flag2 || !data.flag3){

al_wait_cond(cond, mutex);

}
al_unlock_mutex(data.mutex);

I don't need more conds right?

Edit: I have another question... What is the point of having multiple threads if I can't use them to load bitmaps, fonts since they're loaded as memory bitmaps? I guess I have no problem by loading sound on another thread right?

The a wait condition also doesn't spin in a loop using 100% cpu. Where as a simple loop would.

One condition var should be fine so long as the stuff you're waiting for properly sets all flags (or you'll never fully wake up).

I have another question: If the object that I sent to the thread has a function, when I call the function from the main thread do I need to lock the mutex too?

data.cout_this("Hello Thread");

Yes it's possible, if someone wants more info read this: http://www.thinkingparallel.com/2006/10/15/a-short-guide-to-mastering-thread-safety/

BTW I didn't know that rand() wasn't thread-safe...

You need to lock the mutex no matter what (unless you know you've already locked it earlier, otherwise you'll deadlock) for critical sections.

Yhea it's done... Someone has some ideas to create another simple one? I thought in one which multiple threads load a lot of images and make the comparison between using or not threads... But I don't want to load all those images to the wiki, I was thinking if there would be another idea like that, which shows the difference between multi-thread and just one thread very clear.

The C standard doesn't impose thread safety. So it's implementation specific. It's thread safe in MSVC if you compile with the multithreaded C runtime (all C functions are thread safe in that case), but IIRC it isn't in gcc.

The only benefit in loading data from another thread is so that the main thread doesn't block, so you can for example display a small animation in the load screen so the user sees his computer still works . The loading speed is going to be limited by the HDD speed (even if it's an SSD), not by the CPU.