2011-02-23 10:52:22 +00:00
|
|
|
/*
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
* ***** BEGIN GPL LICENSE BLOCK *****
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
2010-02-12 13:34:04 +00:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
*
|
|
|
|
* The Original Code is Copyright (C) 2006 Blender Foundation
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* The Original Code is: all of this file.
|
|
|
|
*
|
|
|
|
* Contributor(s): none yet.
|
|
|
|
*
|
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
|
|
|
*/
|
|
|
|
|
2011-02-27 20:37:56 +00:00
|
|
|
/** \file blender/blenlib/intern/threads.c
|
|
|
|
* \ingroup bli
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
2010-01-22 11:06:57 +00:00
|
|
|
#include <errno.h>
|
2010-04-17 15:47:00 +00:00
|
|
|
#include <string.h>
|
2006-02-25 11:56:08 +00:00
|
|
|
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
2008-12-20 10:02:00 +00:00
|
|
|
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
#include "BLI_blenlib.h"
|
2010-01-22 11:06:57 +00:00
|
|
|
#include "BLI_gsqueue.h"
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
#include "BLI_threads.h"
|
|
|
|
|
2008-08-16 22:47:33 +00:00
|
|
|
#include "PIL_time.h"
|
|
|
|
|
2008-02-21 08:43:13 +00:00
|
|
|
/* for checking system threads - BLI_system_thread_count */
|
2008-02-20 01:12:21 +00:00
|
|
|
#ifdef WIN32
|
2008-12-14 17:32:24 +00:00
|
|
|
#include "windows.h"
|
2010-01-23 14:29:56 +00:00
|
|
|
#include <sys/timeb.h>
|
2008-02-21 08:43:13 +00:00
|
|
|
#elif defined(__APPLE__)
|
2008-02-20 16:07:42 +00:00
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/sysctl.h>
|
2008-02-21 08:43:13 +00:00
|
|
|
#else
|
|
|
|
#include <unistd.h>
|
2010-01-22 21:40:31 +00:00
|
|
|
#include <sys/time.h>
|
2008-02-20 16:07:42 +00:00
|
|
|
#endif
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
|
2010-03-09 16:54:25 +00:00
|
|
|
#if defined(__APPLE__) && (PARALLEL == 1) && (__GNUC__ == 4) && (__GNUC_MINOR__ == 2)
|
|
|
|
/* ************** libgomp (Apple gcc 4.2.1) TLS bug workaround *************** */
|
|
|
|
extern pthread_key_t gomp_tls_key;
|
|
|
|
static void *thread_tls_data;
|
|
|
|
#endif
|
|
|
|
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
/* ********** basic thread control API ************
|
2012-03-03 20:19:11 +00:00
|
|
|
*
|
|
|
|
* Many thread cases have an X amount of jobs, and only an Y amount of
|
|
|
|
* threads are useful (typically amount of cpus)
|
|
|
|
*
|
|
|
|
* This code can be used to start a maximum amount of 'thread slots', which
|
|
|
|
* then can be filled in a loop with an idle timer.
|
|
|
|
*
|
|
|
|
* A sample loop can look like this (pseudo c);
|
|
|
|
*
|
|
|
|
* ListBase lb;
|
|
|
|
* int maxthreads= 2;
|
|
|
|
* int cont= 1;
|
|
|
|
*
|
|
|
|
* BLI_init_threads(&lb, do_something_func, maxthreads);
|
|
|
|
*
|
2012-03-24 06:18:31 +00:00
|
|
|
* while (cont) {
|
2012-03-24 07:52:14 +00:00
|
|
|
* if (BLI_available_threads(&lb) && !(escape loop event)) {
|
2012-03-03 20:19:11 +00:00
|
|
|
* // get new job (data pointer)
|
|
|
|
* // tag job 'processed
|
|
|
|
* BLI_insert_thread(&lb, job);
|
|
|
|
* }
|
|
|
|
* else PIL_sleep_ms(50);
|
|
|
|
*
|
|
|
|
* // find if a job is ready, this the do_something_func() should write in job somewhere
|
|
|
|
* cont= 0;
|
2012-03-24 07:52:14 +00:00
|
|
|
* for (go over all jobs)
|
|
|
|
* if (job is ready) {
|
|
|
|
* if (job was not removed) {
|
2012-03-03 20:19:11 +00:00
|
|
|
* BLI_remove_thread(&lb, job);
|
|
|
|
* }
|
|
|
|
* }
|
|
|
|
* else cont= 1;
|
|
|
|
* }
|
|
|
|
* // conditions to exit loop
|
2012-03-24 07:52:14 +00:00
|
|
|
* if (if escape loop event) {
|
|
|
|
* if (BLI_available_threadslots(&lb)==maxthreads)
|
2012-03-03 20:19:11 +00:00
|
|
|
* break;
|
|
|
|
* }
|
|
|
|
* }
|
|
|
|
*
|
|
|
|
* BLI_end_threads(&lb);
|
|
|
|
*
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
************************************************ */
|
2006-02-25 11:56:08 +00:00
|
|
|
static pthread_mutex_t _malloc_lock = PTHREAD_MUTEX_INITIALIZER;
|
2006-12-21 15:44:46 +00:00
|
|
|
static pthread_mutex_t _image_lock = PTHREAD_MUTEX_INITIALIZER;
|
2009-09-30 18:18:32 +00:00
|
|
|
static pthread_mutex_t _preview_lock = PTHREAD_MUTEX_INITIALIZER;
|
2010-03-16 16:58:45 +00:00
|
|
|
static pthread_mutex_t _viewer_lock = PTHREAD_MUTEX_INITIALIZER;
|
2006-03-13 11:01:17 +00:00
|
|
|
static pthread_mutex_t _custom1_lock = PTHREAD_MUTEX_INITIALIZER;
|
2010-04-15 10:28:32 +00:00
|
|
|
static pthread_mutex_t _rcache_lock = PTHREAD_MUTEX_INITIALIZER;
|
2010-04-25 10:49:13 +00:00
|
|
|
static pthread_mutex_t _opengl_lock = PTHREAD_MUTEX_INITIALIZER;
|
2011-10-31 17:00:59 +00:00
|
|
|
static pthread_mutex_t _nodes_lock = PTHREAD_MUTEX_INITIALIZER;
|
2011-11-07 12:55:18 +00:00
|
|
|
static pthread_mutex_t _movieclip_lock = PTHREAD_MUTEX_INITIALIZER;
|
2010-04-13 12:51:03 +00:00
|
|
|
static pthread_t mainid;
|
2006-11-28 10:16:24 +00:00
|
|
|
static int thread_levels= 0; /* threads can be invoked inside threads */
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
|
|
|
|
/* just a max for security reasons */
|
2010-01-28 19:18:35 +00:00
|
|
|
#define RE_MAX_THREAD BLENDER_MAX_THREADS
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
|
|
|
|
typedef struct ThreadSlot {
|
|
|
|
struct ThreadSlot *next, *prev;
|
2006-02-25 11:56:08 +00:00
|
|
|
void *(*do_thread)(void *);
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
void *callerdata;
|
2006-02-25 11:56:08 +00:00
|
|
|
pthread_t pthread;
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
int avail;
|
|
|
|
} ThreadSlot;
|
|
|
|
|
2009-09-30 18:18:32 +00:00
|
|
|
static void BLI_lock_malloc_thread(void)
|
2006-09-06 19:13:23 +00:00
|
|
|
{
|
|
|
|
pthread_mutex_lock(&_malloc_lock);
|
|
|
|
}
|
|
|
|
|
2009-09-30 18:18:32 +00:00
|
|
|
static void BLI_unlock_malloc_thread(void)
|
2006-09-06 19:13:23 +00:00
|
|
|
{
|
|
|
|
pthread_mutex_unlock(&_malloc_lock);
|
|
|
|
}
|
|
|
|
|
2010-04-13 12:51:03 +00:00
|
|
|
void BLI_threadapi_init(void)
|
|
|
|
{
|
|
|
|
mainid = pthread_self();
|
|
|
|
}
|
|
|
|
|
2007-11-25 16:35:33 +00:00
|
|
|
/* tot = 0 only initializes malloc mutex in a safe way (see sequence.c)
|
2012-03-03 20:19:11 +00:00
|
|
|
* problem otherwise: scene render will kill of the mutex!
|
|
|
|
*/
|
2007-11-25 16:35:33 +00:00
|
|
|
|
2006-02-25 11:56:08 +00:00
|
|
|
void BLI_init_threads(ListBase *threadbase, void *(*do_thread)(void *), int tot)
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
{
|
|
|
|
int a;
|
2010-04-13 12:51:03 +00:00
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
if (threadbase != NULL && tot > 0) {
|
2007-11-25 16:35:33 +00:00
|
|
|
threadbase->first= threadbase->last= NULL;
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
if (tot>RE_MAX_THREAD) tot= RE_MAX_THREAD;
|
|
|
|
else if (tot<1) tot= 1;
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
for (a=0; a<tot; a++) {
|
2007-11-25 16:35:33 +00:00
|
|
|
ThreadSlot *tslot= MEM_callocN(sizeof(ThreadSlot), "threadslot");
|
|
|
|
BLI_addtail(threadbase, tslot);
|
|
|
|
tslot->do_thread= do_thread;
|
|
|
|
tslot->avail= 1;
|
|
|
|
}
|
2010-06-22 15:17:12 +00:00
|
|
|
}
|
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
if (thread_levels == 0) {
|
2010-06-22 15:17:12 +00:00
|
|
|
MEM_set_lock_callback(BLI_lock_malloc_thread, BLI_unlock_malloc_thread);
|
2009-09-30 18:18:32 +00:00
|
|
|
|
2010-03-09 16:54:25 +00:00
|
|
|
#if defined(__APPLE__) && (PARALLEL == 1) && (__GNUC__ == 4) && (__GNUC_MINOR__ == 2)
|
2010-06-22 15:17:12 +00:00
|
|
|
/* workaround for Apple gcc 4.2.1 omp vs background thread bug,
|
2012-03-03 20:19:11 +00:00
|
|
|
* we copy gomp thread local storage pointer to setting it again
|
|
|
|
* inside the thread that we start */
|
2010-06-22 15:17:12 +00:00
|
|
|
thread_tls_data = pthread_getspecific(gomp_tls_key);
|
2010-03-09 16:54:25 +00:00
|
|
|
#endif
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
}
|
2010-06-22 15:17:12 +00:00
|
|
|
|
|
|
|
thread_levels++;
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* amount of available threads */
|
|
|
|
int BLI_available_threads(ListBase *threadbase)
|
|
|
|
{
|
|
|
|
ThreadSlot *tslot;
|
|
|
|
int counter=0;
|
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
for (tslot= threadbase->first; tslot; tslot= tslot->next) {
|
|
|
|
if (tslot->avail)
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
counter++;
|
|
|
|
}
|
|
|
|
return counter;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* returns thread number, for sample patterns or threadsafe tables */
|
|
|
|
int BLI_available_thread_index(ListBase *threadbase)
|
|
|
|
{
|
|
|
|
ThreadSlot *tslot;
|
|
|
|
int counter=0;
|
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
for (tslot= threadbase->first; tslot; tslot= tslot->next, counter++) {
|
|
|
|
if (tslot->avail)
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
return counter;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-03-09 16:54:25 +00:00
|
|
|
static void *tslot_thread_start(void *tslot_p)
|
|
|
|
{
|
|
|
|
ThreadSlot *tslot= (ThreadSlot*)tslot_p;
|
|
|
|
|
|
|
|
#if defined(__APPLE__) && (PARALLEL == 1) && (__GNUC__ == 4) && (__GNUC_MINOR__ == 2)
|
|
|
|
/* workaround for Apple gcc 4.2.1 omp vs background thread bug,
|
2012-03-03 20:19:11 +00:00
|
|
|
* set gomp thread local storage pointer which was copied beforehand */
|
2010-03-09 16:54:25 +00:00
|
|
|
pthread_setspecific (gomp_tls_key, thread_tls_data);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return tslot->do_thread(tslot->callerdata);
|
|
|
|
}
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
|
2011-09-28 05:53:40 +00:00
|
|
|
int BLI_thread_is_main(void)
|
|
|
|
{
|
2010-05-27 12:40:12 +00:00
|
|
|
return pthread_equal(pthread_self(), mainid);
|
2010-04-13 12:51:03 +00:00
|
|
|
}
|
|
|
|
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
void BLI_insert_thread(ListBase *threadbase, void *callerdata)
|
|
|
|
{
|
|
|
|
ThreadSlot *tslot;
|
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
for (tslot= threadbase->first; tslot; tslot= tslot->next) {
|
|
|
|
if (tslot->avail) {
|
2006-02-25 11:56:08 +00:00
|
|
|
tslot->avail= 0;
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
tslot->callerdata= callerdata;
|
2010-03-09 16:54:25 +00:00
|
|
|
pthread_create(&tslot->pthread, NULL, tslot_thread_start, tslot);
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
printf("ERROR: could not insert thread slot\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_remove_thread(ListBase *threadbase, void *callerdata)
|
|
|
|
{
|
|
|
|
ThreadSlot *tslot;
|
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
for (tslot= threadbase->first; tslot; tslot= tslot->next) {
|
|
|
|
if (tslot->callerdata==callerdata) {
|
2006-02-25 11:56:08 +00:00
|
|
|
pthread_join(tslot->pthread, NULL);
|
2010-03-12 13:07:25 +00:00
|
|
|
tslot->callerdata= NULL;
|
2006-02-25 11:56:08 +00:00
|
|
|
tslot->avail= 1;
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-08-14 23:48:52 +00:00
|
|
|
void BLI_remove_thread_index(ListBase *threadbase, int index)
|
|
|
|
{
|
|
|
|
ThreadSlot *tslot;
|
|
|
|
int counter=0;
|
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
for (tslot = threadbase->first; tslot; tslot = tslot->next, counter++) {
|
2008-08-14 23:48:52 +00:00
|
|
|
if (counter == index && tslot->avail == 0) {
|
|
|
|
pthread_join(tslot->pthread, NULL);
|
2010-03-12 13:07:25 +00:00
|
|
|
tslot->callerdata = NULL;
|
2008-08-14 23:48:52 +00:00
|
|
|
tslot->avail = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-09-25 20:29:15 +00:00
|
|
|
void BLI_remove_threads(ListBase *threadbase)
|
|
|
|
{
|
|
|
|
ThreadSlot *tslot;
|
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
for (tslot = threadbase->first; tslot; tslot = tslot->next) {
|
2008-09-25 20:29:15 +00:00
|
|
|
if (tslot->avail == 0) {
|
|
|
|
pthread_join(tslot->pthread, NULL);
|
2010-03-12 13:07:25 +00:00
|
|
|
tslot->callerdata = NULL;
|
2008-09-25 20:29:15 +00:00
|
|
|
tslot->avail = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
void BLI_end_threads(ListBase *threadbase)
|
|
|
|
{
|
|
|
|
ThreadSlot *tslot;
|
|
|
|
|
2009-09-02 20:57:18 +00:00
|
|
|
/* only needed if there's actually some stuff to end
|
|
|
|
* this way we don't end up decrementing thread_levels on an empty threadbase
|
|
|
|
* */
|
|
|
|
if (threadbase && threadbase->first != NULL) {
|
2012-03-24 06:18:31 +00:00
|
|
|
for (tslot= threadbase->first; tslot; tslot= tslot->next) {
|
|
|
|
if (tslot->avail==0) {
|
2007-11-25 16:35:33 +00:00
|
|
|
pthread_join(tslot->pthread, NULL);
|
|
|
|
}
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
}
|
2007-11-25 16:35:33 +00:00
|
|
|
BLI_freelistN(threadbase);
|
Three-in-one commit:
- Compositor now is threaded
Enable it with the Scene buttons "Threads". This will handle over nodes to
individual threads to be calculated. However, if nodes depend on others
they have to wait. The current system only threads per entire node, not for
calculating results in parts.
I've reshuffled the node execution code to evaluate 'changed' events, and
prepare the entire tree to become simply parsed for open jobs with a call
to node = getExecutableNode()
By default, even without 'thread' option active, all node execution is
done within a separate thread.
Also fixed issues in yesterdays commit for 'event based' calculations, it
didn't do animated images, or execute (on rendering) the correct nodes
when you don't have Render-Result nodes included.
- Added generic Thread support in blenlib/ module
The renderer and the node system now both use same code for controlling the
threads. This has been moved to a new C file in blenlib/intern/threads.c.
Check this c file for an extensive doc and example how to use it.
The current implementation for Compositing allows unlimited amount of
threads. For rendering it is still tied to two threads, although it is
pretty easy to extend to 4 already. People with giant amounts of cpus can
poke me once for tests. :)
- Bugfix in creating group nodes
Group node definitions demand a clear separation of 'internal sockets' and
'external sockets'. The first are sockets being linked internally, the latter
are sockets exposed as sockets for the group itself.
When sockets were linked both internal and external, Blender crashed. It is
solved now by removing the external link(s).
2006-01-29 11:36:33 +00:00
|
|
|
}
|
2010-06-22 15:17:12 +00:00
|
|
|
|
|
|
|
thread_levels--;
|
2012-03-24 06:18:31 +00:00
|
|
|
if (thread_levels==0)
|
2010-06-22 15:17:12 +00:00
|
|
|
MEM_set_lock_callback(NULL, NULL);
|
2006-01-30 11:09:50 +00:00
|
|
|
}
|
|
|
|
|
2009-09-30 18:18:32 +00:00
|
|
|
/* System Information */
|
2006-02-11 15:55:00 +00:00
|
|
|
|
2008-02-19 22:23:21 +00:00
|
|
|
/* how many threads are native on this system? */
|
2012-04-29 17:11:40 +00:00
|
|
|
int BLI_system_thread_count(void)
|
2008-02-19 22:23:21 +00:00
|
|
|
{
|
2008-02-19 22:59:52 +00:00
|
|
|
int t;
|
|
|
|
#ifdef WIN32
|
|
|
|
SYSTEM_INFO info;
|
|
|
|
GetSystemInfo(&info);
|
|
|
|
t = (int) info.dwNumberOfProcessors;
|
2008-02-20 16:07:42 +00:00
|
|
|
#else
|
|
|
|
# ifdef __APPLE__
|
|
|
|
int mib[2];
|
|
|
|
size_t len;
|
|
|
|
|
|
|
|
mib[0] = CTL_HW;
|
|
|
|
mib[1] = HW_NCPU;
|
|
|
|
len = sizeof(t);
|
|
|
|
sysctl(mib, 2, &t, &len, NULL, 0);
|
|
|
|
# else
|
2008-02-19 22:59:52 +00:00
|
|
|
t = (int)sysconf(_SC_NPROCESSORS_ONLN);
|
2008-02-20 16:07:42 +00:00
|
|
|
# endif
|
2008-02-19 22:59:52 +00:00
|
|
|
#endif
|
|
|
|
|
2008-02-19 22:23:21 +00:00
|
|
|
if (t>RE_MAX_THREAD)
|
|
|
|
return RE_MAX_THREAD;
|
|
|
|
if (t<1)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
return t;
|
|
|
|
}
|
|
|
|
|
2009-09-30 18:18:32 +00:00
|
|
|
/* Global Mutex Locks */
|
|
|
|
|
|
|
|
void BLI_lock_thread(int type)
|
|
|
|
{
|
|
|
|
if (type==LOCK_IMAGE)
|
|
|
|
pthread_mutex_lock(&_image_lock);
|
|
|
|
else if (type==LOCK_PREVIEW)
|
|
|
|
pthread_mutex_lock(&_preview_lock);
|
2010-03-16 16:58:45 +00:00
|
|
|
else if (type==LOCK_VIEWER)
|
|
|
|
pthread_mutex_lock(&_viewer_lock);
|
2009-09-30 18:18:32 +00:00
|
|
|
else if (type==LOCK_CUSTOM1)
|
|
|
|
pthread_mutex_lock(&_custom1_lock);
|
2010-04-15 10:28:32 +00:00
|
|
|
else if (type==LOCK_RCACHE)
|
|
|
|
pthread_mutex_lock(&_rcache_lock);
|
2010-04-25 10:49:13 +00:00
|
|
|
else if (type==LOCK_OPENGL)
|
|
|
|
pthread_mutex_lock(&_opengl_lock);
|
2011-10-31 17:00:59 +00:00
|
|
|
else if (type==LOCK_NODES)
|
|
|
|
pthread_mutex_lock(&_nodes_lock);
|
2011-11-07 12:55:18 +00:00
|
|
|
else if (type==LOCK_MOVIECLIP)
|
|
|
|
pthread_mutex_lock(&_movieclip_lock);
|
2009-09-30 18:18:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_unlock_thread(int type)
|
|
|
|
{
|
|
|
|
if (type==LOCK_IMAGE)
|
|
|
|
pthread_mutex_unlock(&_image_lock);
|
|
|
|
else if (type==LOCK_PREVIEW)
|
|
|
|
pthread_mutex_unlock(&_preview_lock);
|
2010-03-16 16:58:45 +00:00
|
|
|
else if (type==LOCK_VIEWER)
|
|
|
|
pthread_mutex_unlock(&_viewer_lock);
|
2012-03-24 06:18:31 +00:00
|
|
|
else if (type==LOCK_CUSTOM1)
|
2009-09-30 18:18:32 +00:00
|
|
|
pthread_mutex_unlock(&_custom1_lock);
|
2012-03-24 06:18:31 +00:00
|
|
|
else if (type==LOCK_RCACHE)
|
2010-04-26 12:50:48 +00:00
|
|
|
pthread_mutex_unlock(&_rcache_lock);
|
2012-03-24 06:18:31 +00:00
|
|
|
else if (type==LOCK_OPENGL)
|
2010-04-25 10:49:13 +00:00
|
|
|
pthread_mutex_unlock(&_opengl_lock);
|
2012-03-24 06:18:31 +00:00
|
|
|
else if (type==LOCK_NODES)
|
2011-10-31 17:00:59 +00:00
|
|
|
pthread_mutex_unlock(&_nodes_lock);
|
2012-03-24 06:18:31 +00:00
|
|
|
else if (type==LOCK_MOVIECLIP)
|
2011-11-07 12:55:18 +00:00
|
|
|
pthread_mutex_unlock(&_movieclip_lock);
|
2009-09-30 18:18:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Mutex Locks */
|
|
|
|
|
|
|
|
void BLI_mutex_init(ThreadMutex *mutex)
|
|
|
|
{
|
|
|
|
pthread_mutex_init(mutex, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_mutex_lock(ThreadMutex *mutex)
|
|
|
|
{
|
|
|
|
pthread_mutex_lock(mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_mutex_unlock(ThreadMutex *mutex)
|
|
|
|
{
|
|
|
|
pthread_mutex_unlock(mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_mutex_end(ThreadMutex *mutex)
|
|
|
|
{
|
|
|
|
pthread_mutex_destroy(mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Read/Write Mutex Lock */
|
|
|
|
|
|
|
|
void BLI_rw_mutex_init(ThreadRWMutex *mutex)
|
|
|
|
{
|
|
|
|
pthread_rwlock_init(mutex, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_rw_mutex_lock(ThreadRWMutex *mutex, int mode)
|
|
|
|
{
|
2012-03-24 06:18:31 +00:00
|
|
|
if (mode == THREAD_LOCK_READ)
|
2009-09-30 18:18:32 +00:00
|
|
|
pthread_rwlock_rdlock(mutex);
|
|
|
|
else
|
|
|
|
pthread_rwlock_wrlock(mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_rw_mutex_unlock(ThreadRWMutex *mutex)
|
|
|
|
{
|
|
|
|
pthread_rwlock_unlock(mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_rw_mutex_end(ThreadRWMutex *mutex)
|
|
|
|
{
|
|
|
|
pthread_rwlock_destroy(mutex);
|
|
|
|
}
|
|
|
|
|
2008-08-16 22:47:33 +00:00
|
|
|
/* ************************************************ */
|
|
|
|
|
|
|
|
typedef struct ThreadedWorker {
|
|
|
|
ListBase threadbase;
|
|
|
|
void *(*work_fnct)(void *);
|
|
|
|
char busy[RE_MAX_THREAD];
|
|
|
|
int total;
|
|
|
|
int sleep_time;
|
|
|
|
} ThreadedWorker;
|
|
|
|
|
|
|
|
typedef struct WorkParam {
|
|
|
|
ThreadedWorker *worker;
|
|
|
|
void *param;
|
|
|
|
int index;
|
|
|
|
} WorkParam;
|
|
|
|
|
2009-09-14 16:52:06 +00:00
|
|
|
static void *exec_work_fnct(void *v_param)
|
2008-08-16 22:47:33 +00:00
|
|
|
{
|
|
|
|
WorkParam *p = (WorkParam*)v_param;
|
|
|
|
void *value;
|
|
|
|
|
|
|
|
value = p->worker->work_fnct(p->param);
|
|
|
|
|
|
|
|
p->worker->busy[p->index] = 0;
|
|
|
|
MEM_freeN(p);
|
|
|
|
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
ThreadedWorker *BLI_create_worker(void *(*do_thread)(void *), int tot, int sleep_time)
|
|
|
|
{
|
|
|
|
ThreadedWorker *worker;
|
|
|
|
|
2010-10-16 14:32:17 +00:00
|
|
|
(void)sleep_time; /* unused */
|
|
|
|
|
2008-08-16 22:47:33 +00:00
|
|
|
worker = MEM_callocN(sizeof(ThreadedWorker), "threadedworker");
|
|
|
|
|
2012-03-06 18:40:15 +00:00
|
|
|
if (tot > RE_MAX_THREAD) {
|
2008-08-16 22:47:33 +00:00
|
|
|
tot = RE_MAX_THREAD;
|
|
|
|
}
|
2012-03-06 18:40:15 +00:00
|
|
|
else if (tot < 1) {
|
2008-08-16 22:47:33 +00:00
|
|
|
tot= 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
worker->total = tot;
|
|
|
|
worker->work_fnct = do_thread;
|
|
|
|
|
|
|
|
BLI_init_threads(&worker->threadbase, exec_work_fnct, tot);
|
|
|
|
|
|
|
|
return worker;
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_end_worker(ThreadedWorker *worker)
|
|
|
|
{
|
2008-09-25 20:29:15 +00:00
|
|
|
BLI_remove_threads(&worker->threadbase);
|
2008-08-16 22:47:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_destroy_worker(ThreadedWorker *worker)
|
|
|
|
{
|
|
|
|
BLI_end_worker(worker);
|
|
|
|
BLI_freelistN(&worker->threadbase);
|
|
|
|
MEM_freeN(worker);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_insert_work(ThreadedWorker *worker, void *param)
|
|
|
|
{
|
|
|
|
WorkParam *p = MEM_callocN(sizeof(WorkParam), "workparam");
|
|
|
|
int index;
|
|
|
|
|
2012-03-06 18:40:15 +00:00
|
|
|
if (BLI_available_threads(&worker->threadbase) == 0) {
|
2008-08-16 22:47:33 +00:00
|
|
|
index = worker->total;
|
2012-03-24 06:18:31 +00:00
|
|
|
while (index == worker->total) {
|
2008-08-16 22:47:33 +00:00
|
|
|
PIL_sleep_ms(worker->sleep_time);
|
|
|
|
|
2012-03-06 18:40:15 +00:00
|
|
|
for (index = 0; index < worker->total; index++) {
|
|
|
|
if (worker->busy[index] == 0) {
|
2008-08-16 22:47:33 +00:00
|
|
|
BLI_remove_thread_index(&worker->threadbase, index);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2012-03-06 18:40:15 +00:00
|
|
|
else {
|
2008-08-16 22:47:33 +00:00
|
|
|
index = BLI_available_thread_index(&worker->threadbase);
|
|
|
|
}
|
|
|
|
|
|
|
|
worker->busy[index] = 1;
|
|
|
|
|
|
|
|
p->param = param;
|
|
|
|
p->index = index;
|
|
|
|
p->worker = worker;
|
|
|
|
|
|
|
|
BLI_insert_thread(&worker->threadbase, p);
|
|
|
|
}
|
|
|
|
|
2010-01-22 11:06:57 +00:00
|
|
|
/* ************************************************ */
|
|
|
|
|
|
|
|
struct ThreadQueue {
|
|
|
|
GSQueue *queue;
|
|
|
|
pthread_mutex_t mutex;
|
|
|
|
pthread_cond_t cond;
|
|
|
|
int nowait;
|
|
|
|
};
|
|
|
|
|
2011-02-13 15:02:21 +00:00
|
|
|
ThreadQueue *BLI_thread_queue_init(void)
|
2010-01-22 11:06:57 +00:00
|
|
|
{
|
|
|
|
ThreadQueue *queue;
|
|
|
|
|
|
|
|
queue= MEM_callocN(sizeof(ThreadQueue), "ThreadQueue");
|
|
|
|
queue->queue= BLI_gsqueue_new(sizeof(void*));
|
|
|
|
|
|
|
|
pthread_mutex_init(&queue->mutex, NULL);
|
|
|
|
pthread_cond_init(&queue->cond, NULL);
|
|
|
|
|
|
|
|
return queue;
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_thread_queue_free(ThreadQueue *queue)
|
|
|
|
{
|
|
|
|
pthread_cond_destroy(&queue->cond);
|
|
|
|
pthread_mutex_destroy(&queue->mutex);
|
|
|
|
|
|
|
|
BLI_gsqueue_free(queue->queue);
|
|
|
|
|
|
|
|
MEM_freeN(queue);
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_thread_queue_push(ThreadQueue *queue, void *work)
|
|
|
|
{
|
|
|
|
pthread_mutex_lock(&queue->mutex);
|
|
|
|
|
|
|
|
BLI_gsqueue_push(queue->queue, &work);
|
|
|
|
|
|
|
|
/* signal threads waiting to pop */
|
|
|
|
pthread_cond_signal(&queue->cond);
|
|
|
|
pthread_mutex_unlock(&queue->mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
void *BLI_thread_queue_pop(ThreadQueue *queue)
|
|
|
|
{
|
|
|
|
void *work= NULL;
|
|
|
|
|
|
|
|
/* wait until there is work */
|
|
|
|
pthread_mutex_lock(&queue->mutex);
|
2012-03-24 06:18:31 +00:00
|
|
|
while (BLI_gsqueue_is_empty(queue->queue) && !queue->nowait)
|
2010-01-22 11:06:57 +00:00
|
|
|
pthread_cond_wait(&queue->cond, &queue->mutex);
|
|
|
|
|
|
|
|
/* if we have something, pop it */
|
2012-03-24 06:18:31 +00:00
|
|
|
if (!BLI_gsqueue_is_empty(queue->queue))
|
2010-01-22 11:06:57 +00:00
|
|
|
BLI_gsqueue_pop(queue->queue, &work);
|
|
|
|
|
|
|
|
pthread_mutex_unlock(&queue->mutex);
|
|
|
|
|
|
|
|
return work;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void wait_timeout(struct timespec *timeout, int ms)
|
|
|
|
{
|
|
|
|
ldiv_t div_result;
|
2010-01-23 14:29:56 +00:00
|
|
|
long sec, usec, x;
|
2010-01-22 11:06:57 +00:00
|
|
|
|
2010-01-23 14:29:56 +00:00
|
|
|
#ifdef WIN32
|
|
|
|
{
|
|
|
|
struct _timeb now;
|
|
|
|
_ftime(&now);
|
|
|
|
sec = now.time;
|
|
|
|
usec = now.millitm*1000; /* microsecond precision would be better */
|
2010-01-22 11:06:57 +00:00
|
|
|
}
|
2010-01-23 11:25:20 +00:00
|
|
|
#else
|
2010-01-23 14:29:56 +00:00
|
|
|
{
|
|
|
|
struct timeval now;
|
|
|
|
gettimeofday(&now, NULL);
|
|
|
|
sec = now.tv_sec;
|
|
|
|
usec = now.tv_usec;
|
|
|
|
}
|
|
|
|
#endif
|
2010-01-23 11:25:20 +00:00
|
|
|
|
2010-01-23 14:29:56 +00:00
|
|
|
/* add current time + millisecond offset */
|
2010-01-23 11:25:20 +00:00
|
|
|
div_result = ldiv(ms, 1000);
|
2010-01-23 14:29:56 +00:00
|
|
|
timeout->tv_sec = sec + div_result.quot;
|
|
|
|
|
|
|
|
x = usec + (div_result.rem*1000);
|
2010-01-23 11:25:20 +00:00
|
|
|
|
|
|
|
if (x >= 1000000) {
|
|
|
|
timeout->tv_sec++;
|
|
|
|
x -= 1000000;
|
|
|
|
}
|
|
|
|
|
|
|
|
timeout->tv_nsec = x*1000;
|
2010-01-22 11:06:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void *BLI_thread_queue_pop_timeout(ThreadQueue *queue, int ms)
|
|
|
|
{
|
|
|
|
double t;
|
|
|
|
void *work= NULL;
|
|
|
|
struct timespec timeout;
|
|
|
|
|
|
|
|
t= PIL_check_seconds_timer();
|
|
|
|
wait_timeout(&timeout, ms);
|
|
|
|
|
|
|
|
/* wait until there is work */
|
|
|
|
pthread_mutex_lock(&queue->mutex);
|
2012-03-24 06:18:31 +00:00
|
|
|
while (BLI_gsqueue_is_empty(queue->queue) && !queue->nowait) {
|
|
|
|
if (pthread_cond_timedwait(&queue->cond, &queue->mutex, &timeout) == ETIMEDOUT)
|
2010-01-22 11:06:57 +00:00
|
|
|
break;
|
2012-03-24 06:18:31 +00:00
|
|
|
else if (PIL_check_seconds_timer() - t >= ms*0.001)
|
2010-01-22 11:06:57 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* if we have something, pop it */
|
2012-03-24 06:18:31 +00:00
|
|
|
if (!BLI_gsqueue_is_empty(queue->queue))
|
2010-01-22 11:06:57 +00:00
|
|
|
BLI_gsqueue_pop(queue->queue, &work);
|
|
|
|
|
|
|
|
pthread_mutex_unlock(&queue->mutex);
|
|
|
|
|
|
|
|
return work;
|
|
|
|
}
|
|
|
|
|
|
|
|
int BLI_thread_queue_size(ThreadQueue *queue)
|
|
|
|
{
|
|
|
|
int size;
|
|
|
|
|
|
|
|
pthread_mutex_lock(&queue->mutex);
|
|
|
|
size= BLI_gsqueue_size(queue->queue);
|
|
|
|
pthread_mutex_unlock(&queue->mutex);
|
|
|
|
|
|
|
|
return size;
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_thread_queue_nowait(ThreadQueue *queue)
|
|
|
|
{
|
|
|
|
pthread_mutex_lock(&queue->mutex);
|
|
|
|
|
|
|
|
queue->nowait= 1;
|
|
|
|
|
|
|
|
/* signal threads waiting to pop */
|
|
|
|
pthread_cond_signal(&queue->cond);
|
|
|
|
pthread_mutex_unlock(&queue->mutex);
|
|
|
|
}
|
|
|
|
|
2011-10-22 16:16:14 +00:00
|
|
|
void BLI_begin_threaded_malloc(void)
|
|
|
|
{
|
2012-03-24 06:18:31 +00:00
|
|
|
if (thread_levels == 0) {
|
2011-10-22 16:16:14 +00:00
|
|
|
MEM_set_lock_callback(BLI_lock_malloc_thread, BLI_unlock_malloc_thread);
|
|
|
|
}
|
|
|
|
thread_levels++;
|
|
|
|
}
|
|
|
|
|
|
|
|
void BLI_end_threaded_malloc(void)
|
|
|
|
{
|
|
|
|
thread_levels--;
|
2012-03-24 06:18:31 +00:00
|
|
|
if (thread_levels==0)
|
2011-10-22 16:16:14 +00:00
|
|
|
MEM_set_lock_callback(NULL, NULL);
|
2011-11-10 17:43:37 +00:00
|
|
|
}
|