2010-10-14 08:30:07 +02:00
|
|
|
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
|
2012-06-13 14:17:57 +01:00
|
|
|
/*
|
|
|
|
* This file is part of the LibreOffice project.
|
|
|
|
*
|
|
|
|
* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
*
|
|
|
|
* This file incorporates work covered by the following license notice:
|
|
|
|
*
|
|
|
|
* Licensed to the Apache Software Foundation (ASF) under one or more
|
|
|
|
* contributor license agreements. See the NOTICE file distributed
|
|
|
|
* with this work for additional information regarding copyright
|
|
|
|
* ownership. The ASF licenses this file to you under the Apache
|
|
|
|
* License, Version 2.0 (the "License"); you may not use this file
|
|
|
|
* except in compliance with the License. You may obtain a copy of
|
|
|
|
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
|
|
|
|
*/
|
2006-09-16 23:20:10 +00:00
|
|
|
|
2012-05-16 22:09:21 +02:00
|
|
|
#include "sal/config.h"
|
|
|
|
|
|
|
|
#include <cassert>
|
2014-12-27 21:01:22 +00:00
|
|
|
#include <unordered_map>
|
2000-09-18 14:29:57 +00:00
|
|
|
#include <stdio.h>
|
|
|
|
|
|
|
|
#include <osl/diagnose.h>
|
|
|
|
#include <osl/mutex.hxx>
|
|
|
|
#include <osl/thread.h>
|
2010-10-11 10:41:50 +01:00
|
|
|
#include <rtl/instance.hxx>
|
2014-11-14 16:05:37 +01:00
|
|
|
#include <sal/log.hxx>
|
2000-09-18 14:29:57 +00:00
|
|
|
|
|
|
|
#include <uno/threadpool.h>
|
|
|
|
|
|
|
|
#include "threadpool.hxx"
|
|
|
|
#include "thread.hxx"
|
|
|
|
|
|
|
|
using namespace ::std;
|
|
|
|
using namespace ::osl;
|
2014-05-19 00:36:42 +02:00
|
|
|
using namespace ::rtl;
|
2000-09-18 14:29:57 +00:00
|
|
|
|
|
|
|
namespace cppu_threadpool
|
|
|
|
{
|
2010-10-11 10:41:50 +01:00
|
|
|
struct theDisposedCallerAdmin :
|
|
|
|
public rtl::StaticWithInit< DisposedCallerAdminHolder, theDisposedCallerAdmin >
|
2006-04-26 19:50:31 +00:00
|
|
|
{
|
2010-10-11 10:41:50 +01:00
|
|
|
DisposedCallerAdminHolder operator () () {
|
|
|
|
return DisposedCallerAdminHolder(new DisposedCallerAdmin());
|
2006-04-26 19:50:31 +00:00
|
|
|
}
|
2010-10-11 10:41:50 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
DisposedCallerAdminHolder DisposedCallerAdmin::getInstance()
|
|
|
|
{
|
|
|
|
return theDisposedCallerAdmin::get();
|
2006-04-26 19:50:31 +00:00
|
|
|
}
|
|
|
|
|
2000-09-18 14:29:57 +00:00
|
|
|
DisposedCallerAdmin::~DisposedCallerAdmin()
|
|
|
|
{
|
2003-04-15 15:37:01 +00:00
|
|
|
#if OSL_DEBUG_LEVEL > 1
|
2000-09-18 14:29:57 +00:00
|
|
|
if( !m_lst.empty() )
|
|
|
|
{
|
2007-07-18 11:22:02 +00:00
|
|
|
printf( "DisposedCallerList : %lu left\n" , static_cast<unsigned long>(m_lst.size( )));
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
void DisposedCallerAdmin::dispose( sal_Int64 nDisposeId )
|
|
|
|
{
|
|
|
|
MutexGuard guard( m_mutex );
|
|
|
|
m_lst.push_back( nDisposeId );
|
|
|
|
}
|
|
|
|
|
2012-05-16 22:09:21 +02:00
|
|
|
void DisposedCallerAdmin::destroy( sal_Int64 nDisposeId )
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
|
|
|
MutexGuard guard( m_mutex );
|
|
|
|
for( DisposedCallerList::iterator ii = m_lst.begin() ;
|
|
|
|
ii != m_lst.end() ;
|
|
|
|
++ ii )
|
|
|
|
{
|
|
|
|
if( (*ii) == nDisposeId )
|
|
|
|
{
|
|
|
|
m_lst.erase( ii );
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-15 17:39:35 +01:00
|
|
|
bool DisposedCallerAdmin::isDisposed( sal_Int64 nDisposeId )
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
|
|
|
MutexGuard guard( m_mutex );
|
|
|
|
for( DisposedCallerList::iterator ii = m_lst.begin() ;
|
|
|
|
ii != m_lst.end() ;
|
|
|
|
++ ii )
|
|
|
|
{
|
|
|
|
if( (*ii) == nDisposeId )
|
|
|
|
{
|
2014-02-15 17:39:35 +01:00
|
|
|
return true;
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
}
|
2014-02-15 17:39:35 +01:00
|
|
|
return false;
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2010-10-11 10:41:50 +01:00
|
|
|
|
|
|
|
ThreadPool::ThreadPool()
|
|
|
|
{
|
|
|
|
m_DisposedCallerAdmin = DisposedCallerAdmin::getInstance();
|
|
|
|
}
|
|
|
|
|
2000-09-18 14:29:57 +00:00
|
|
|
ThreadPool::~ThreadPool()
|
|
|
|
{
|
2003-04-15 15:37:01 +00:00
|
|
|
#if OSL_DEBUG_LEVEL > 1
|
2000-09-18 14:29:57 +00:00
|
|
|
if( m_mapQueue.size() )
|
|
|
|
{
|
2007-07-18 11:22:02 +00:00
|
|
|
printf( "ThreadIdHashMap : %lu left\n" , static_cast<unsigned long>(m_mapQueue.size()) );
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
void ThreadPool::dispose( sal_Int64 nDisposeId )
|
|
|
|
{
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
m_DisposedCallerAdmin->dispose( nDisposeId );
|
2001-02-20 13:44:41 +00:00
|
|
|
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
MutexGuard guard( m_mutex );
|
|
|
|
for( ThreadIdHashMap::iterator ii = m_mapQueue.begin() ;
|
|
|
|
ii != m_mapQueue.end();
|
|
|
|
++ii)
|
|
|
|
{
|
|
|
|
if( (*ii).second.first )
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
(*ii).second.first->dispose( nDisposeId );
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
if( (*ii).second.second )
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
(*ii).second.second->dispose( nDisposeId );
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-05-16 22:09:21 +02:00
|
|
|
void ThreadPool::destroy( sal_Int64 nDisposeId )
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
2012-05-16 22:09:21 +02:00
|
|
|
m_DisposedCallerAdmin->destroy( nDisposeId );
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/******************
|
|
|
|
* This methods lets the thread wait a certain amount of time. If within this timespan
|
|
|
|
* a new request comes in, this thread is reused. This is done only to improve performance,
|
|
|
|
* it is not required for threadpool functionality.
|
|
|
|
******************/
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
void ThreadPool::waitInPool( rtl::Reference< ORequestThread > const & pThread )
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
|
|
|
struct WaitingThread waitingThread;
|
|
|
|
waitingThread.condition = osl_createCondition();
|
|
|
|
waitingThread.thread = pThread;
|
|
|
|
{
|
|
|
|
MutexGuard guard( m_mutexWaitingThreadList );
|
|
|
|
m_lstThreads.push_front( &waitingThread );
|
|
|
|
}
|
|
|
|
|
|
|
|
// let the thread wait 2 seconds
|
|
|
|
TimeValue time = { 2 , 0 };
|
|
|
|
osl_waitCondition( waitingThread.condition , &time );
|
|
|
|
|
|
|
|
{
|
|
|
|
MutexGuard guard ( m_mutexWaitingThreadList );
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
if( waitingThread.thread.is() )
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
|
|
|
// thread wasn't reused, remove it from the list
|
|
|
|
WaitingThreadList::iterator ii = find(
|
|
|
|
m_lstThreads.begin(), m_lstThreads.end(), &waitingThread );
|
|
|
|
OSL_ASSERT( ii != m_lstThreads.end() );
|
|
|
|
m_lstThreads.erase( ii );
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
osl_destroyCondition( waitingThread.condition );
|
|
|
|
}
|
|
|
|
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
void ThreadPool::joinWorkers()
|
|
|
|
{
|
|
|
|
{
|
|
|
|
MutexGuard guard( m_mutexWaitingThreadList );
|
|
|
|
for( WaitingThreadList::iterator ii = m_lstThreads.begin() ;
|
|
|
|
ii != m_lstThreads.end() ;
|
|
|
|
++ ii )
|
|
|
|
{
|
|
|
|
// wake the threads up
|
|
|
|
osl_setCondition( (*ii)->condition );
|
|
|
|
}
|
|
|
|
}
|
|
|
|
m_aThreadAdmin.join();
|
|
|
|
}
|
|
|
|
|
2014-11-14 16:05:37 +01:00
|
|
|
bool ThreadPool::createThread( JobQueue *pQueue ,
|
2000-09-18 14:29:57 +00:00
|
|
|
const ByteSequence &aThreadId,
|
2014-02-15 17:39:35 +01:00
|
|
|
bool bAsynchron )
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
|
|
|
{
|
|
|
|
// Can a thread be reused ?
|
|
|
|
MutexGuard guard( m_mutexWaitingThreadList );
|
|
|
|
if( ! m_lstThreads.empty() )
|
|
|
|
{
|
|
|
|
// inform the thread and let it go
|
|
|
|
struct WaitingThread *pWaitingThread = m_lstThreads.back();
|
|
|
|
pWaitingThread->thread->setTask( pQueue , aThreadId , bAsynchron );
|
|
|
|
pWaitingThread->thread = 0;
|
|
|
|
|
|
|
|
// remove from list
|
|
|
|
m_lstThreads.pop_back();
|
|
|
|
|
|
|
|
// let the thread go
|
|
|
|
osl_setCondition( pWaitingThread->condition );
|
2014-11-14 16:05:37 +01:00
|
|
|
return true;
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-11-14 16:05:37 +01:00
|
|
|
rtl::Reference< ORequestThread > pThread(
|
|
|
|
new ORequestThread( this, pQueue , aThreadId, bAsynchron) );
|
|
|
|
return pThread->launch();
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
|
2014-02-15 17:39:35 +01:00
|
|
|
bool ThreadPool::revokeQueue( const ByteSequence &aThreadId, bool bAsynchron )
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
|
|
|
MutexGuard guard( m_mutex );
|
|
|
|
|
|
|
|
ThreadIdHashMap::iterator ii = m_mapQueue.find( aThreadId );
|
|
|
|
OSL_ASSERT( ii != m_mapQueue.end() );
|
|
|
|
|
|
|
|
if( bAsynchron )
|
|
|
|
{
|
|
|
|
if( ! (*ii).second.second->isEmpty() )
|
|
|
|
{
|
|
|
|
// another thread has put something into the queue
|
2014-02-15 17:39:35 +01:00
|
|
|
return false;
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
(*ii).second.second = 0;
|
|
|
|
if( (*ii).second.first )
|
|
|
|
{
|
|
|
|
// all oneway request have been processed, now
|
|
|
|
// synchronus requests may go on
|
|
|
|
(*ii).second.first->resume();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if( ! (*ii).second.first->isEmpty() )
|
|
|
|
{
|
|
|
|
// another thread has put something into the queue
|
2014-02-15 17:39:35 +01:00
|
|
|
return false;
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
(*ii).second.first = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if( 0 == (*ii).second.first && 0 == (*ii).second.second )
|
|
|
|
{
|
|
|
|
m_mapQueue.erase( ii );
|
|
|
|
}
|
|
|
|
|
2014-02-15 17:39:35 +01:00
|
|
|
return true;
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-11-14 16:05:37 +01:00
|
|
|
bool ThreadPool::addJob(
|
2000-09-18 14:29:57 +00:00
|
|
|
const ByteSequence &aThreadId ,
|
2014-02-15 17:39:35 +01:00
|
|
|
bool bAsynchron,
|
2000-09-18 14:29:57 +00:00
|
|
|
void *pThreadSpecificData,
|
2006-06-19 12:12:45 +00:00
|
|
|
RequestFun * doRequest )
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
2014-02-15 17:39:35 +01:00
|
|
|
bool bCreateThread = false;
|
2000-09-18 14:29:57 +00:00
|
|
|
JobQueue *pQueue = 0;
|
|
|
|
{
|
|
|
|
MutexGuard guard( m_mutex );
|
|
|
|
|
|
|
|
ThreadIdHashMap::iterator ii = m_mapQueue.find( aThreadId );
|
|
|
|
|
|
|
|
if( ii == m_mapQueue.end() )
|
|
|
|
{
|
2011-03-14 12:18:51 +02:00
|
|
|
m_mapQueue[ aThreadId ] = pair < JobQueue * , JobQueue * > ( (JobQueue *)0 , (JobQueue*)0 );
|
2000-09-18 14:29:57 +00:00
|
|
|
ii = m_mapQueue.find( aThreadId );
|
|
|
|
OSL_ASSERT( ii != m_mapQueue.end() );
|
|
|
|
}
|
|
|
|
|
|
|
|
if( bAsynchron )
|
|
|
|
{
|
|
|
|
if( ! (*ii).second.second )
|
|
|
|
{
|
2006-06-19 12:12:45 +00:00
|
|
|
(*ii).second.second = new JobQueue();
|
2014-02-15 17:39:35 +01:00
|
|
|
bCreateThread = true;
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
pQueue = (*ii).second.second;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if( ! (*ii).second.first )
|
|
|
|
{
|
2006-06-19 12:12:45 +00:00
|
|
|
(*ii).second.first = new JobQueue();
|
2014-02-15 17:39:35 +01:00
|
|
|
bCreateThread = true;
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
pQueue = (*ii).second.first;
|
|
|
|
|
|
|
|
if( (*ii).second.second && ( (*ii).second.second->isBusy() ) )
|
|
|
|
{
|
|
|
|
pQueue->suspend();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
pQueue->add( pThreadSpecificData , doRequest );
|
|
|
|
}
|
|
|
|
|
2014-11-14 16:05:37 +01:00
|
|
|
return !bCreateThread || createThread( pQueue , aThreadId , bAsynchron);
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void ThreadPool::prepare( const ByteSequence &aThreadId )
|
|
|
|
{
|
|
|
|
MutexGuard guard( m_mutex );
|
|
|
|
|
|
|
|
ThreadIdHashMap::iterator ii = m_mapQueue.find( aThreadId );
|
|
|
|
|
|
|
|
if( ii == m_mapQueue.end() )
|
|
|
|
{
|
2006-06-19 12:12:45 +00:00
|
|
|
JobQueue *p = new JobQueue();
|
2011-03-14 12:18:51 +02:00
|
|
|
m_mapQueue[ aThreadId ] = pair< JobQueue * , JobQueue * > ( p , (JobQueue*)0 );
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
else if( 0 == (*ii).second.first )
|
|
|
|
{
|
2006-06-19 12:12:45 +00:00
|
|
|
(*ii).second.first = new JobQueue();
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void * ThreadPool::enter( const ByteSequence & aThreadId , sal_Int64 nDisposeId )
|
|
|
|
{
|
|
|
|
JobQueue *pQueue = 0;
|
|
|
|
{
|
|
|
|
MutexGuard guard( m_mutex );
|
|
|
|
|
|
|
|
ThreadIdHashMap::iterator ii = m_mapQueue.find( aThreadId );
|
|
|
|
|
|
|
|
OSL_ASSERT( ii != m_mapQueue.end() );
|
|
|
|
pQueue = (*ii).second.first;
|
|
|
|
}
|
|
|
|
|
|
|
|
OSL_ASSERT( pQueue );
|
2006-04-26 19:50:31 +00:00
|
|
|
void *pReturn = pQueue->enter( nDisposeId );
|
2000-09-18 14:29:57 +00:00
|
|
|
|
|
|
|
if( pQueue->isCallstackEmpty() )
|
|
|
|
{
|
2014-02-15 17:39:35 +01:00
|
|
|
if( revokeQueue( aThreadId , false) )
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
|
|
|
// remove queue
|
|
|
|
delete pQueue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return pReturn;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
// All uno_ThreadPool handles in g_pThreadpoolHashSet with overlapping life
|
|
|
|
// spans share one ThreadPool instance. When g_pThreadpoolHashSet becomes empty
|
|
|
|
// (within the last uno_threadpool_destroy) all worker threads spawned by that
|
|
|
|
// ThreadPool instance are joined (which implies that uno_threadpool_destroy
|
|
|
|
// must never be called from a worker thread); afterwards, the next call to
|
|
|
|
// uno_threadpool_create (if any) will lead to a new ThreadPool instance.
|
2000-09-18 14:29:57 +00:00
|
|
|
|
|
|
|
using namespace cppu_threadpool;
|
|
|
|
|
2001-05-10 10:59:37 +00:00
|
|
|
struct uno_ThreadPool_Equal
|
|
|
|
{
|
2014-02-15 17:39:35 +01:00
|
|
|
bool operator () ( const uno_ThreadPool &a , const uno_ThreadPool &b ) const
|
2001-05-10 10:59:37 +00:00
|
|
|
{
|
|
|
|
return a == b;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
struct uno_ThreadPool_Hash
|
|
|
|
{
|
2004-06-17 11:45:43 +00:00
|
|
|
sal_Size operator () ( const uno_ThreadPool &a ) const
|
2001-05-10 10:59:37 +00:00
|
|
|
{
|
2014-09-11 15:25:48 +02:00
|
|
|
return reinterpret_cast<sal_Size>( a );
|
2001-05-10 10:59:37 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-27 21:01:22 +00:00
|
|
|
typedef std::unordered_map< uno_ThreadPool, ThreadPoolHolder, uno_ThreadPool_Hash, uno_ThreadPool_Equal > ThreadpoolHashSet;
|
2001-05-10 10:59:37 +00:00
|
|
|
|
|
|
|
static ThreadpoolHashSet *g_pThreadpoolHashSet;
|
|
|
|
|
|
|
|
struct _uno_ThreadPool
|
|
|
|
{
|
|
|
|
sal_Int32 dummy;
|
|
|
|
};
|
|
|
|
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
namespace {
|
|
|
|
|
|
|
|
ThreadPoolHolder getThreadPool( uno_ThreadPool hPool )
|
|
|
|
{
|
|
|
|
MutexGuard guard( Mutex::getGlobalMutex() );
|
|
|
|
assert( g_pThreadpoolHashSet != 0 );
|
|
|
|
ThreadpoolHashSet::iterator i( g_pThreadpoolHashSet->find(hPool) );
|
|
|
|
assert( i != g_pThreadpoolHashSet->end() );
|
|
|
|
return i->second;
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2011-12-19 11:32:43 +01:00
|
|
|
extern "C" uno_ThreadPool SAL_CALL
|
2001-05-08 14:55:56 +00:00
|
|
|
uno_threadpool_create() SAL_THROW_EXTERN_C()
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
2001-05-10 10:59:37 +00:00
|
|
|
MutexGuard guard( Mutex::getGlobalMutex() );
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
ThreadPoolHolder p;
|
2001-05-10 10:59:37 +00:00
|
|
|
if( ! g_pThreadpoolHashSet )
|
|
|
|
{
|
|
|
|
g_pThreadpoolHashSet = new ThreadpoolHashSet();
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
p = new ThreadPool;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
assert( !g_pThreadpoolHashSet->empty() );
|
|
|
|
p = g_pThreadpoolHashSet->begin()->second;
|
2001-05-10 10:59:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Just ensure that the handle is unique in the process (via heap)
|
|
|
|
uno_ThreadPool h = new struct _uno_ThreadPool;
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
g_pThreadpoolHashSet->insert( ThreadpoolHashSet::value_type(h, p) );
|
2001-05-08 14:55:56 +00:00
|
|
|
return h;
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
|
2011-12-19 11:32:43 +01:00
|
|
|
extern "C" void SAL_CALL
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
uno_threadpool_attach( uno_ThreadPool hPool ) SAL_THROW_EXTERN_C()
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
2001-05-08 14:55:56 +00:00
|
|
|
sal_Sequence *pThreadId = 0;
|
|
|
|
uno_getIdOfCurrentThread( &pThreadId );
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
getThreadPool( hPool )->prepare( pThreadId );
|
2001-05-08 14:55:56 +00:00
|
|
|
rtl_byte_sequence_release( pThreadId );
|
|
|
|
uno_releaseIdFromCurrentThread();
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
|
2011-12-19 11:32:43 +01:00
|
|
|
extern "C" void SAL_CALL
|
2001-05-08 14:55:56 +00:00
|
|
|
uno_threadpool_enter( uno_ThreadPool hPool , void **ppJob )
|
2001-03-09 11:10:57 +00:00
|
|
|
SAL_THROW_EXTERN_C()
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
|
|
|
sal_Sequence *pThreadId = 0;
|
|
|
|
uno_getIdOfCurrentThread( &pThreadId );
|
2006-04-26 19:50:31 +00:00
|
|
|
*ppJob =
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
getThreadPool( hPool )->enter(
|
2006-06-19 12:12:45 +00:00
|
|
|
pThreadId,
|
|
|
|
sal::static_int_cast< sal_Int64 >(
|
|
|
|
reinterpret_cast< sal_IntPtr >(hPool)) );
|
2000-09-18 14:29:57 +00:00
|
|
|
rtl_byte_sequence_release( pThreadId );
|
2001-05-08 14:55:56 +00:00
|
|
|
uno_releaseIdFromCurrentThread();
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
|
2011-12-19 11:32:43 +01:00
|
|
|
extern "C" void SAL_CALL
|
2012-01-21 15:21:16 +01:00
|
|
|
uno_threadpool_detach(SAL_UNUSED_PARAMETER uno_ThreadPool) SAL_THROW_EXTERN_C()
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
2001-05-08 14:55:56 +00:00
|
|
|
// we might do here some tiding up in case a thread called attach but never detach
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
|
2011-12-19 11:32:43 +01:00
|
|
|
extern "C" void SAL_CALL
|
2001-05-08 14:55:56 +00:00
|
|
|
uno_threadpool_putJob(
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
uno_ThreadPool hPool,
|
2001-05-08 14:55:56 +00:00
|
|
|
sal_Sequence *pThreadId,
|
|
|
|
void *pJob,
|
|
|
|
void ( SAL_CALL * doRequest ) ( void *pThreadSpecificData ),
|
|
|
|
sal_Bool bIsOneway ) SAL_THROW_EXTERN_C()
|
|
|
|
{
|
2014-11-14 16:05:37 +01:00
|
|
|
if (!getThreadPool(hPool)->addJob( pThreadId, bIsOneway, pJob ,doRequest ))
|
|
|
|
{
|
|
|
|
SAL_WARN(
|
|
|
|
"cppu",
|
|
|
|
"uno_threadpool_putJob in parallel with uno_threadpool_destroy");
|
|
|
|
}
|
2001-05-08 14:55:56 +00:00
|
|
|
}
|
2000-09-18 14:29:57 +00:00
|
|
|
|
2011-12-19 11:32:43 +01:00
|
|
|
extern "C" void SAL_CALL
|
2001-05-08 14:55:56 +00:00
|
|
|
uno_threadpool_dispose( uno_ThreadPool hPool ) SAL_THROW_EXTERN_C()
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
getThreadPool(hPool)->dispose(
|
2006-06-19 12:12:45 +00:00
|
|
|
sal::static_int_cast< sal_Int64 >(
|
|
|
|
reinterpret_cast< sal_IntPtr >(hPool)) );
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
|
|
|
|
2011-12-19 11:32:43 +01:00
|
|
|
extern "C" void SAL_CALL
|
2001-05-08 14:55:56 +00:00
|
|
|
uno_threadpool_destroy( uno_ThreadPool hPool ) SAL_THROW_EXTERN_C()
|
2000-09-18 14:29:57 +00:00
|
|
|
{
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
ThreadPoolHolder p( getThreadPool(hPool) );
|
|
|
|
p->destroy(
|
2006-06-19 12:12:45 +00:00
|
|
|
sal::static_int_cast< sal_Int64 >(
|
|
|
|
reinterpret_cast< sal_IntPtr >(hPool)) );
|
2001-05-10 10:59:37 +00:00
|
|
|
|
2012-05-16 22:09:21 +02:00
|
|
|
bool empty;
|
2001-05-10 10:59:37 +00:00
|
|
|
{
|
|
|
|
OSL_ASSERT( g_pThreadpoolHashSet );
|
|
|
|
|
|
|
|
MutexGuard guard( Mutex::getGlobalMutex() );
|
|
|
|
|
|
|
|
ThreadpoolHashSet::iterator ii = g_pThreadpoolHashSet->find( hPool );
|
|
|
|
OSL_ASSERT( ii != g_pThreadpoolHashSet->end() );
|
|
|
|
g_pThreadpoolHashSet->erase( ii );
|
|
|
|
delete hPool;
|
|
|
|
|
2012-05-16 22:09:21 +02:00
|
|
|
empty = g_pThreadpoolHashSet->empty();
|
|
|
|
if( empty )
|
2001-05-10 10:59:37 +00:00
|
|
|
{
|
|
|
|
delete g_pThreadpoolHashSet;
|
|
|
|
g_pThreadpoolHashSet = 0;
|
|
|
|
}
|
|
|
|
}
|
2012-05-16 22:09:21 +02:00
|
|
|
|
|
|
|
if( empty )
|
|
|
|
{
|
Better fix for ThreadPool/ORequestThread life cycle
This is a follow up to d015384e1d98fe77fd59339044f58efb1ab9fb25 "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:
* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.
That has been addressed by giving Bridge::dispose new semantics: It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined. (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)
* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.
That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock. (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)
* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.
That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.
Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f
2012-05-23 09:42:37 +02:00
|
|
|
p->joinWorkers();
|
2012-05-16 22:09:21 +02:00
|
|
|
}
|
2000-09-18 14:29:57 +00:00
|
|
|
}
|
2010-10-14 08:30:07 +02:00
|
|
|
|
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|