You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "weijin (Created) (JIRA)" <ji...@apache.org> on 2011/10/12 12:15:11 UTC
[jira] [Created] (TS-980) change client_session schedule from
global to thread local, and reduce the try_locks in
UnixNetVConnection::reenable
change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable
---------------------------------------------------------------------------------------------------------------------
Key: TS-980
URL: https://issues.apache.org/jira/browse/TS-980
Project: Traffic Server
Issue Type: Improvement
Components: Network, Performance
Affects Versions: 3.0.0, 3.1.0
Environment: all
Reporter: weijin
Assignee: weijin
I did some performance test on ats last days(disable cache, set share_server session 2, pure proxy mode), I did see significant improvement on low load, but it dropped rapidly when load is high. meanwhile, some stability problems happened. Through gdb, I found the client_session`s mutex can be acquired by two or more threads, I believe some schedules happened during the sm life_time. May be we need do some work to find these eventProcessor.schedules and change them to thread schedules.
UnixVConnecton::reenable {
if (nh->mutex->thread_holding == t) {
// put into ready_list
} else {
MUTEX_TRY_LOCK(lock, nh->mutex, t);
if (!lock) {
// put into enable_list;
} else {
// put into ready_list;
}
}
remove UnixNetVConnection::reenable try_lock operations, 3 reasons
1. try_lock operation means obj allocation and deallocation operation. frequently
2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule by as soon as possible)
3. try_lock should not acquire the net-handler`s mutex. That may lead more net io latency if it is an epoll event need to be processed in other threads. If it is not an epoll event(time event), I don`t think putting vc in ready_list has any advantage than in enable_list.
may be we can change reenale function like this:
UnixVConnecton::reenable {
if (nh->mutex->thread_holding == t) {
// put into ready_list;
} else {
// put into enable_list;
}
my buddies, any advice?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-980) change client_session schedule from
global to thread local, and reduce the try_locks in
UnixNetVConnection::reenable
Posted by "weijin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128043#comment-13128043 ]
weijin commented on TS-980:
---------------------------
http_sm can be callback by different threads even use share sessions in thread mode. in most cases, the callbacks happends in one thread, there may come up an exception when http_sms(different threads) do the dns query in the same time. Through the sources, I found HostDBContinuation::remove_trigger_pending_dns can callsback http_sm which was created by other threads. This is an extreme condition and have little effect on performance. I also give a patch on this ticket because it takes me 3 days to figure out the reason.
> change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: TS-980
> URL: https://issues.apache.org/jira/browse/TS-980
> Project: Traffic Server
> Issue Type: Improvement
> Components: Network, Performance
> Affects Versions: 3.1.0, 3.0.0
> Environment: all
> Reporter: weijin
> Assignee: weijin
> Fix For: 3.1.2
>
>
> I did some performance test on ats last days(disable cache, set share_server session 2, pure proxy mode), I did see significant improvement on low load, but it dropped rapidly when load is high. meanwhile, some stability problems happened. Through gdb, I found the client_session`s mutex can be acquired by two or more threads, I believe some schedules happened during the sm life_time. May be we need do some work to find these eventProcessor.schedules and change them to thread schedules.
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list
> } else {
> MUTEX_TRY_LOCK(lock, nh->mutex, t);
> if (!lock) {
> // put into enable_list;
> } else {
> // put into ready_list;
> }
> }
> remove UnixNetVConnection::reenable try_lock operations, 3 reasons
> 1. try_lock operation means obj allocation and deallocation operation. frequently
> 2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule by as soon as possible)
> 3. try_lock should not acquire the net-handler`s mutex. That may lead more net io latency if it is an epoll event need to be processed in other threads. If it is not an epoll event(time event), I don`t think putting vc in ready_list has any advantage than in enable_list.
> may be we can change reenale function like this:
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list;
> } else {
> // put into enable_list;
> }
> my buddies, any advice?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-980) change client_session schedule from
global to thread local, and reduce the try_locks in
UnixNetVConnection::reenable
Posted by "Leif Hedstrom (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190551#comment-13190551 ]
Leif Hedstrom commented on TS-980:
----------------------------------
Two things:
1) When i first wrote that code, I couldn't use that thread mutex, due to a dead lock scenario.
2) When i try this patch, it usually segfaults pretty fast, I've seen a few different backtraces, but they generally seem to happen in DNS. See example stack trace below.
I'm going to move this out to 3.1.4 for now, please move it as appropriate.
{code}
(gdb) bt
#0 ink_restore_signal_handler_frame (signalhandler_frame=3, len=9, stack=0x7f4dc71545d0) at ink_stack_trace.cc:68
#1 ink_stack_trace_get (signalhandler_frame=2, stack=0x7f4dc71545d0, len=<optimized out>) at ink_stack_trace.cc:89
#2 ink_stack_trace_dump (sighandler_frame=2) at ink_stack_trace.cc:114
#3 0x00000000004e1dd3 in signal_handler (sig=11) at signals.cc:222
#4 <signal handler called>
#5 HostDBContinuation::dnsEvent (this=0x7f4dc6729650, event=1, e=0x23a1a10) at HostDB.cc:1331
#6 0x00000000006aca20 in handleEvent (data=0x23a1a10, event=1, this=<optimized out>) at I_Continuation.h:146
#7 EThread::process_event (this=0x7f4dc765c010, e=0x23a1a10, calling_code=1) at UnixEThread.cc:142
#8 0x00000000006ad5db in EThread::execute (this=0x7f4dc765c010) at UnixEThread.cc:191
#9 0x00000000006ab732 in spawn_thread_internal (a=0x209f180) at Thread.cc:88
#10 0x00007f4dcc9ddd90 in start_thread (arg=0x7f4dc7156700) at pthread_create.c:309
#11 0x00007f4dca14f48d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
00007ffff533848d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
{code}
> change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: TS-980
> URL: https://issues.apache.org/jira/browse/TS-980
> Project: Traffic Server
> Issue Type: Improvement
> Components: Network, Performance
> Affects Versions: 3.1.0, 3.0.0
> Environment: all
> Reporter: weijin
> Assignee: weijin
> Fix For: 3.1.4
>
> Attachments: ts-980.diff
>
>
> I did some performance test on ats last days(disable cache, set share_server session 2, pure proxy mode), I did see significant improvement on low load, but it dropped rapidly when load is high. meanwhile, some stability problems happened. Through gdb, I found the client_session`s mutex can be acquired by two or more threads, I believe some schedules happened during the sm life_time. May be we need do some work to find these eventProcessor.schedules and change them to thread schedules.
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list
> } else {
> MUTEX_TRY_LOCK(lock, nh->mutex, t);
> if (!lock) {
> // put into enable_list;
> } else {
> // put into ready_list;
> }
> }
> remove UnixNetVConnection::reenable try_lock operations, 3 reasons
> 1. try_lock operation means obj allocation and deallocation operation. frequently
> 2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule by as soon as possible)
> 3. try_lock should not acquire the net-handler`s mutex. That may lead more net io latency if it is an epoll event need to be processed in other threads. If it is not an epoll event(time event), I don`t think putting vc in ready_list has any advantage than in enable_list.
> may be we can change reenale function like this:
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list;
> } else {
> // put into enable_list;
> }
> my buddies, any advice?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-980) change client_session schedule from
global to thread local, and reduce the try_locks in
UnixNetVConnection::reenable
Posted by "Leif Hedstrom (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181865#comment-13181865 ]
Leif Hedstrom commented on TS-980:
----------------------------------
Is this ready for review? If so, please assign it to me, and I'll take a look.
Thanks!
-- leif
> change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: TS-980
> URL: https://issues.apache.org/jira/browse/TS-980
> Project: Traffic Server
> Issue Type: Improvement
> Components: Network, Performance
> Affects Versions: 3.1.0, 3.0.0
> Environment: all
> Reporter: weijin
> Assignee: weijin
> Fix For: 3.1.2
>
> Attachments: ts-980.diff
>
>
> I did some performance test on ats last days(disable cache, set share_server session 2, pure proxy mode), I did see significant improvement on low load, but it dropped rapidly when load is high. meanwhile, some stability problems happened. Through gdb, I found the client_session`s mutex can be acquired by two or more threads, I believe some schedules happened during the sm life_time. May be we need do some work to find these eventProcessor.schedules and change them to thread schedules.
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list
> } else {
> MUTEX_TRY_LOCK(lock, nh->mutex, t);
> if (!lock) {
> // put into enable_list;
> } else {
> // put into ready_list;
> }
> }
> remove UnixNetVConnection::reenable try_lock operations, 3 reasons
> 1. try_lock operation means obj allocation and deallocation operation. frequently
> 2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule by as soon as possible)
> 3. try_lock should not acquire the net-handler`s mutex. That may lead more net io latency if it is an epoll event need to be processed in other threads. If it is not an epoll event(time event), I don`t think putting vc in ready_list has any advantage than in enable_list.
> may be we can change reenale function like this:
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list;
> } else {
> // put into enable_list;
> }
> my buddies, any advice?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-980) change client_session schedule from
global to thread local, and reduce the try_locks in
UnixNetVConnection::reenable
Posted by "weijin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144692#comment-13144692 ]
weijin commented on TS-980:
---------------------------
I also added some logics to reduce the possibility of acquiring the expire sessions.
> change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: TS-980
> URL: https://issues.apache.org/jira/browse/TS-980
> Project: Traffic Server
> Issue Type: Improvement
> Components: Network, Performance
> Affects Versions: 3.1.0, 3.0.0
> Environment: all
> Reporter: weijin
> Assignee: weijin
> Fix For: 3.1.2
>
> Attachments: ts-980.diff
>
>
> I did some performance test on ats last days(disable cache, set share_server session 2, pure proxy mode), I did see significant improvement on low load, but it dropped rapidly when load is high. meanwhile, some stability problems happened. Through gdb, I found the client_session`s mutex can be acquired by two or more threads, I believe some schedules happened during the sm life_time. May be we need do some work to find these eventProcessor.schedules and change them to thread schedules.
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list
> } else {
> MUTEX_TRY_LOCK(lock, nh->mutex, t);
> if (!lock) {
> // put into enable_list;
> } else {
> // put into ready_list;
> }
> }
> remove UnixNetVConnection::reenable try_lock operations, 3 reasons
> 1. try_lock operation means obj allocation and deallocation operation. frequently
> 2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule by as soon as possible)
> 3. try_lock should not acquire the net-handler`s mutex. That may lead more net io latency if it is an epoll event need to be processed in other threads. If it is not an epoll event(time event), I don`t think putting vc in ready_list has any advantage than in enable_list.
> may be we can change reenale function like this:
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list;
> } else {
> // put into enable_list;
> }
> my buddies, any advice?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-980) change client_session schedule from
global to thread local, and reduce the try_locks in
UnixNetVConnection::reenable
Posted by "Leif Hedstrom (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-980:
-----------------------------
Fix Version/s: (was: 3.1.2)
3.1.4
> change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: TS-980
> URL: https://issues.apache.org/jira/browse/TS-980
> Project: Traffic Server
> Issue Type: Improvement
> Components: Network, Performance
> Affects Versions: 3.1.0, 3.0.0
> Environment: all
> Reporter: weijin
> Assignee: weijin
> Fix For: 3.1.4
>
> Attachments: ts-980.diff
>
>
> I did some performance test on ats last days(disable cache, set share_server session 2, pure proxy mode), I did see significant improvement on low load, but it dropped rapidly when load is high. meanwhile, some stability problems happened. Through gdb, I found the client_session`s mutex can be acquired by two or more threads, I believe some schedules happened during the sm life_time. May be we need do some work to find these eventProcessor.schedules and change them to thread schedules.
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list
> } else {
> MUTEX_TRY_LOCK(lock, nh->mutex, t);
> if (!lock) {
> // put into enable_list;
> } else {
> // put into ready_list;
> }
> }
> remove UnixNetVConnection::reenable try_lock operations, 3 reasons
> 1. try_lock operation means obj allocation and deallocation operation. frequently
> 2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule by as soon as possible)
> 3. try_lock should not acquire the net-handler`s mutex. That may lead more net io latency if it is an epoll event need to be processed in other threads. If it is not an epoll event(time event), I don`t think putting vc in ready_list has any advantage than in enable_list.
> may be we can change reenale function like this:
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list;
> } else {
> // put into enable_list;
> }
> my buddies, any advice?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-980) change client_session schedule from
global to thread local, and reduce the try_locks in
UnixNetVConnection::reenable
Posted by "Leif Hedstrom (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-980:
-----------------------------
Fix Version/s: 3.1.2
> change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: TS-980
> URL: https://issues.apache.org/jira/browse/TS-980
> Project: Traffic Server
> Issue Type: Improvement
> Components: Network, Performance
> Affects Versions: 3.1.0, 3.0.0
> Environment: all
> Reporter: weijin
> Assignee: weijin
> Fix For: 3.1.2
>
>
> I did some performance test on ats last days(disable cache, set share_server session 2, pure proxy mode), I did see significant improvement on low load, but it dropped rapidly when load is high. meanwhile, some stability problems happened. Through gdb, I found the client_session`s mutex can be acquired by two or more threads, I believe some schedules happened during the sm life_time. May be we need do some work to find these eventProcessor.schedules and change them to thread schedules.
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list
> } else {
> MUTEX_TRY_LOCK(lock, nh->mutex, t);
> if (!lock) {
> // put into enable_list;
> } else {
> // put into ready_list;
> }
> }
> remove UnixNetVConnection::reenable try_lock operations, 3 reasons
> 1. try_lock operation means obj allocation and deallocation operation. frequently
> 2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule by as soon as possible)
> 3. try_lock should not acquire the net-handler`s mutex. That may lead more net io latency if it is an epoll event need to be processed in other threads. If it is not an epoll event(time event), I don`t think putting vc in ready_list has any advantage than in enable_list.
> may be we can change reenale function like this:
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list;
> } else {
> // put into enable_list;
> }
> my buddies, any advice?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-980) change client_session schedule from
global to thread local, and reduce the try_locks in
UnixNetVConnection::reenable
Posted by "weijin (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
weijin updated TS-980:
----------------------
Attachment: ts-980.diff
I bind the nethandle`s mutex as thread mutex to avoid other threads try to lock it. The thread session buckets` mutex are converted back to thread mutex, because the netvc:do_io_read require the cont`s mutex should be hold by current thread.
> change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: TS-980
> URL: https://issues.apache.org/jira/browse/TS-980
> Project: Traffic Server
> Issue Type: Improvement
> Components: Network, Performance
> Affects Versions: 3.1.0, 3.0.0
> Environment: all
> Reporter: weijin
> Assignee: weijin
> Fix For: 3.1.2
>
> Attachments: ts-980.diff
>
>
> I did some performance test on ats last days(disable cache, set share_server session 2, pure proxy mode), I did see significant improvement on low load, but it dropped rapidly when load is high. meanwhile, some stability problems happened. Through gdb, I found the client_session`s mutex can be acquired by two or more threads, I believe some schedules happened during the sm life_time. May be we need do some work to find these eventProcessor.schedules and change them to thread schedules.
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list
> } else {
> MUTEX_TRY_LOCK(lock, nh->mutex, t);
> if (!lock) {
> // put into enable_list;
> } else {
> // put into ready_list;
> }
> }
> remove UnixNetVConnection::reenable try_lock operations, 3 reasons
> 1. try_lock operation means obj allocation and deallocation operation. frequently
> 2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule by as soon as possible)
> 3. try_lock should not acquire the net-handler`s mutex. That may lead more net io latency if it is an epoll event need to be processed in other threads. If it is not an epoll event(time event), I don`t think putting vc in ready_list has any advantage than in enable_list.
> may be we can change reenale function like this:
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list;
> } else {
> // put into enable_list;
> }
> my buddies, any advice?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-980) change client_session schedule from
global to thread local, and reduce the try_locks in
UnixNetVConnection::reenable
Posted by "Zhao Yongming (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Zhao Yongming updated TS-980:
-----------------------------
Fix Version/s: (was: 3.1.4)
3.3.0
reschedule to 3.3.0, may need more tweak & testing
> change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: TS-980
> URL: https://issues.apache.org/jira/browse/TS-980
> Project: Traffic Server
> Issue Type: Improvement
> Components: Network, Performance
> Affects Versions: 3.1.0, 3.0.0
> Environment: all
> Reporter: weijin
> Assignee: weijin
> Fix For: 3.3.0
>
> Attachments: ts-980.diff
>
>
> I did some performance test on ats last days(disable cache, set share_server session 2, pure proxy mode), I did see significant improvement on low load, but it dropped rapidly when load is high. meanwhile, some stability problems happened. Through gdb, I found the client_session`s mutex can be acquired by two or more threads, I believe some schedules happened during the sm life_time. May be we need do some work to find these eventProcessor.schedules and change them to thread schedules.
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list
> } else {
> MUTEX_TRY_LOCK(lock, nh->mutex, t);
> if (!lock) {
> // put into enable_list;
> } else {
> // put into ready_list;
> }
> }
> remove UnixNetVConnection::reenable try_lock operations, 3 reasons
> 1. try_lock operation means obj allocation and deallocation operation. frequently
> 2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule by as soon as possible)
> 3. try_lock should not acquire the net-handler`s mutex. That may lead more net io latency if it is an epoll event need to be processed in other threads. If it is not an epoll event(time event), I don`t think putting vc in ready_list has any advantage than in enable_list.
> may be we can change reenale function like this:
> UnixVConnecton::reenable {
> if (nh->mutex->thread_holding == t) {
> // put into ready_list;
> } else {
> // put into enable_list;
> }
> my buddies, any advice?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira