Difference between revisions of "Performance/load performance implement parallel mutex"
Zengliangjun (Talk | contribs) |
Zengliangjun (Talk | contribs) (→Solve C) |
||
| (10 intermediate revisions by the same user not shown) | |||
| Line 15: | Line 15: | ||
= Analysis = | = Analysis = | ||
We can understand OOo had three type mutex. | We can understand OOo had three type mutex. | ||
| − | ''' | + | *''' Global Mutex''': It can be get from '''osl::Mutex::getGlobalMutex()''', and can be used at a simple critical which lock section no other mutex. |
| − | ''' | + | *'''Solar Mutex''': It can be get from '''Application::GetSolarMutex()''', and can be used any where. which lock section can had other mutex, and can be spin lock. It's used at the uno implement class's method section, main function is synchronization UNO environment. |
| − | ''' | + | *'''General Mutex''': It can be used other thread and OOo main thread, etc. Which can be as same type. |
So, Dead lock will be, It like this: | So, Dead lock will be, It like this: | ||
[[Image:Parallel dead lock.jpg]] | [[Image:Parallel dead lock.jpg]] | ||
| − | |||
| − | + | = Solve = | |
| + | It will be new parallel_mutex model, so we must let the 'Solar Mutex' will not acquire at parallel section; It is ease. | ||
| − | + | [[Image:Parallel dead lock solve.JPG]] | |
| − | + | == Problem == | |
| + | But there will synchronization problem; where the base struct like svarray(svl) and std::vector etc. be there. | ||
| − | So we can design 'Solar Mutex' has two mutex objects, One synchronize at general section and One synchronize at parallel section. How 'Solar Mutex' can know it is general or parallel section; | + | == Solve A == |
| + | We must let the 'Solar Mutex' synchronization at parallel section, so there are an other mutex object. | ||
| + | |||
| + | So we can design 'Solar Mutex' has two mutex objects, One synchronize at general section and One synchronize at parallel section. How 'Solar Mutex' can know it is general or parallel section; there are function ''omp_in_parallel()'' in OpenMP . Now It like this: | ||
[[Image:Parallel dead lock solve 1.JPG]] | [[Image:Parallel dead lock solve 1.JPG]] | ||
| − | Ok, that | + | Ok, that is right, Yes it not wrong. But performance no improve. I think it is that the synchronize section is much block. So the processing is multithread, But all most time only one thread can runing, and other thread is block. |
| + | |||
| + | == Solve B == | ||
| + | Can we let those structs are all thread safe? | ||
| + | That can improve the performance? The consuming from thread safe will .... | ||
| + | And Do that can solve this problem? | ||
| + | |||
| + | == Solve C == | ||
| + | Can we think the relation like document -> page -> shape -> .... | ||
| − | So | + | When create one shape, the document will add some info about shape, So document's data will be in multi-thread context. Can we reorder the operator create the relation of document with shape, let that will be at the page had process finished. |
| − | + | ||
| − | + | [[Category:Performance]] | |
Latest revision as of 05:05, 31 May 2010
|
|
|---|
|
Quick Navigation Team Communication Activities |
| About this template |
Please view Performance/load_performance_implement about implement. This document explain parallel and dead lock problem and resolve plan.
Problem
Now I'd finished the part of odf impress's code, and wish is:
settings.xml when processing the <office:settings> element, it's subelement will be parallel processed.
styles.xml when processing the <office:styles> and <office:automatic-styles> and <office:master-styles> elements, it's subelement will be parallel processed.
content.xml when processing the <office:presentation> and styles's elements, it's subelement will be parallel processed.
When running, that will dead lock.
Analysis
We can understand OOo had three type mutex.
- Global Mutex: It can be get from osl::Mutex::getGlobalMutex(), and can be used at a simple critical which lock section no other mutex.
- Solar Mutex: It can be get from Application::GetSolarMutex(), and can be used any where. which lock section can had other mutex, and can be spin lock. It's used at the uno implement class's method section, main function is synchronization UNO environment.
- General Mutex: It can be used other thread and OOo main thread, etc. Which can be as same type.
So, Dead lock will be, It like this:
Solve
It will be new parallel_mutex model, so we must let the 'Solar Mutex' will not acquire at parallel section; It is ease.
Problem
But there will synchronization problem; where the base struct like svarray(svl) and std::vector etc. be there.
Solve A
We must let the 'Solar Mutex' synchronization at parallel section, so there are an other mutex object.
So we can design 'Solar Mutex' has two mutex objects, One synchronize at general section and One synchronize at parallel section. How 'Solar Mutex' can know it is general or parallel section; there are function omp_in_parallel() in OpenMP . Now It like this:
Ok, that is right, Yes it not wrong. But performance no improve. I think it is that the synchronize section is much block. So the processing is multithread, But all most time only one thread can runing, and other thread is block.
Solve B
Can we let those structs are all thread safe? That can improve the performance? The consuming from thread safe will .... And Do that can solve this problem?
Solve C
Can we think the relation like document -> page -> shape -> ....
When create one shape, the document will add some info about shape, So document's data will be in multi-thread context. Can we reorder the operator create the relation of document with shape, let that will be at the page had process finished.
