Aleric Inglewood 09708b6318 Added AICondition.
AICondition is like AIThreadSafeSimpleDC (it is derived from it),
and wraps some variable, protecting it with a builtin mutex.

While in a statemachine, one can call wait(condition) to make
the state machine go idle, and call condition.signal() to
wake it (or another) up again.

While normally a condition variable is used as follows:

condition.lock();
while (!whatwerewaitingfor)
{
  condition.wait();
}
// Here the condition is guaranteed to be true and we're
// still in the critical area of the mutex.
condition.unlock();

where the thread blocks in wait(), the statemachine actually
returns CPU to the thread (the AIEngine), so there is no
while loop involved, and our wait() doesn't even unlock
the mutex: that happens because the state machine returns:

condition_wat condition_w(condition);		// Lock condition.
if (!condition_w->whatwerewaitingfor())		// The variable(s) involved can only be accessed when condition is locked.
{
  wait(condition);				// Causes the state machine to go idle. This does not block.
  break;					// Leave scope (unlock condition) and return to the mainloop - but as idle state machine.
}
// Here the condition is guaranteed to be true and we're
// still in the critical area of the condition variable.

In this case, when condition.signal() is called, the thread
doesn't return from wait() with a locked mutex - but the
statemachine executes the same state again, and enters from
the top: locking the condition and doing the test again,
just like it would be when this was a while loop.
2013-10-15 22:30:53 +02:00
2013-10-15 22:30:53 +02:00
2012-09-08 02:03:07 -04:00
2013-10-02 17:49:57 +02:00
2012-08-21 19:17:45 +02:00
2013-10-07 17:06:14 +02:00
2013-05-25 18:26:42 +03:00

00000000011111111112222222222333333333344444444445555555555666666666677777777778
12345678901234567890123456789012345678901234567890123456789012345678901234567890
       ______ ___ __   _  _____ _    _       ______  _____ ___ _____ _   _
       |_____  |  | \  | |  ___ |    | |     |____| |____/  |    |    \_/  
       _____| _|_ |  \_| |____| |____| |____ |    | |   \_ _|_   |     |   
                                               _  _ _ ____ _  _ ____ ____
                                                \/  | |=== |/\| |=== |--<

Sin-gu-la-ri-ty (noun) - a distinctive feature, a uniqueness; a point at which
continuity breaks up; a point in history at which machine becomes smarter than 
humanity and/or fuses with it indivisively; or simply a cool sounding word with 
the initials S.G. in it :)
	
Singularity Viewer is a SecondLife(tm) protocol compatible client application.
It can be used to access SecondLife services as well as a number of others such
as those based upon the OpenSim platform.

Singularity is maintained by a small group of volunteers who can be contacted
both, in-world (SingularityViewer group) as well as on IRC (#SingularityViewer
@ FreeNode). Bug requests and features requests can be submitted through our
Issue Tracker (http://code.google.com/p/singularity-viewer/issues/list or from
the viewer menu: Help --> Bug Reporting --> Singularity Issue Tracker...)


As this Readme grows out of date, please refer to 

	http://www.singularityviewer.org/about


00000000011111111112222222222333333333344444444445555555555666666666677777777778
12345678901234567890123456789012345678901234567890123456789012345678901234567890

History

The Singularity viewer was started by Siana Gearz in November 2010 by forking it
from the Ascent Viewer, by Balseraph Software Group, which in turn was based upon
source code modified from the snowglobe source code released by Linden Lab.

Description
An experimental Snowglobe 1.5 based Second Life Viewer focusing on performance, but also including all the usual conveniences and RLVa.
Readme 145 MiB
Languages
C++ 84.1%
Rez 7.6%
C 2.6%
SQLPL 1.6%
GLSL 1.6%
Other 2.3%