Performance/Meetings/2010 05
|
|
|---|
|
Quick Navigation Team Communication Activities |
| About this template |
Performance/Meetings/2010/05/28
Meeting Minutes
IRC Meeting of ORACLE with RedOffice
Performance Project
Date: 2010/05/28
Agenda:
Performance/Meetings/2010/05/21
Meeting Minutes
IRC Meeting of ORACLE with RedOffice
Performance Project
Date: 2010/05/21
Agenda:
<LiHeng>hi,what's up?
<yujinliang>hi
<liangjun>hi
<LiHeng>hi,all
<LiHeng>waiting for mhu
<liangjun>:)
<yujinliang>:-D
<mhu>Hi all, sorry for being late
<LiHeng>hi mhu
<LiHeng>Don't mind
<LiHeng>let's update our status
<liangjun>hi mhu :)
<yujinliang>hi mhu
<mhu>hi all
<mhu>liangjun: in your email to Kay Ramme, you again talked about things not thread-safe in Uno. I think I still don't understand what you mean. Can you explain, what exactly you found to be not thread safe, please ?
<liangjun>my status: I had update the cws and then loadofd can package on windows.
<LiHeng>My status:I am working the extension of new sd-filter that can load specified part of a document, to make partly load simple
<mhu>okay, that is good. So, someone (me) can look at that cws (loadofd).
<yujinliang>My status: now i major on fixing redoffice and trying to fix some openoffice bugs, such as issue108805
<liangjun>mhu: my mean is the memory and base data struct are not thread safe. :) and I try to make it will be thread safe .
<mhu>which memory, and base data struct do you mean ?
<mhu>... that is a very general statement, I think
<liangjun>rtl_allocmemory.
<mhu>well, rtl_allocMemory() *is* thread-safe.
<mhu>...can you explain in more detail, what does not work for you ?
<liangjun>mhu: okey
<mhu>... there may of course always be undiscovered bugs
<liangjun>http://wiki.services.openoffice.org/wiki/Performance/load_performance_implement_parallel_mutex
<mhu>liangjun: please give me some time, to read that in detail. I just skipped over it. But, there is definitely no need to protect memory allocation and refcounting with external mutex, they are already thread-safe internally by design.
<liangjun>mhu: okey
<mhu>I will read that page (and think about it) until next friday latest, maybe I answer via email.
<mhu>just as a quick explanation: refcounting is done with osl_incrementInterlockedCount(), which is based (on x86) on the "LOCK XADD" processor instruction. You can look that up in the intel documentation. rtl_allocateMemory() uses an internal mutex, so that it can be called from many threads in parallel without problems (and without deadlocks).
<LiHeng>Thanks
<liangjun>mhu: thank you, okey. and I 'm fixing the detail on my computer( It is compiling , I can't get the result.)
<mhu>okay
<liangjun>mhu: I read it is thread safe, but I running the office it will error.
<mhu>what error, when ? can you explain ?
<liangjun>It is null point error.
<mhu>oh, but what has that to do with thread safe or not ?
<liangjun>So I add mutex on osl_incrementInterlockedCount and rtl_allocateMemory .
<mhu>are you saying that you have two threads calling rtl_allocateMemory() in parallel and one returns with a null pointer ?
<liangjun>and the tools::Container
<liangjun>mhu: no
<liangjun>I can't where are the null pointer
<liangjun>I can't check where are the null pointer
<mhu>can we leave out "high level" classes like tools:Container, and concentrate on rtl_allocateMemory() for the moment ?
<liangjun>So I do it
<mhu>okay, so it is not rtl_allocateMemory() that is failing, but some code using that memory, right ?
<liangjun>mhu: yes I think so
<mhu>access to the allocated memory of course needs to be protected.
<liangjun>So I add the mutex on it.
<mhu>you added a mutex to what ?
<liangjun>to rtl_allocateMemory()
<mhu>no, that must be wrong, as we just discussed
<mhu>I guess, what you mean is some code like this ...
<mhu>struct { mutex m_mutex; void * m_memory; }
<liangjun>mhu: I know your mean
<mhu>lock (s.m_mutex); s.m_memory = rtl_allocMem(); fill (s.m_memory); unlock (s.m_mutex);
<mhu>so, what you protect is the logic accessing the memory, not the call to rtl_allocMemory()
<mhu>another thread needs to do. ..
<mhu>lock (s.m_mutex); s.m_memmory[7] = 42; unlock(s.m_mutex);
<mhu>again, this has nothing to do with rtl_allocMemory
<liangjun>void * SAL_CALL rtl_allocateMemory (sal_Size n)
<liangjun>{
<liangjun>void * pResult = NULL;
<liangjun>osl_enterMemorySection();
<liangjun>pResult = malloc (n);
<liangjun>osl_leaveMemorySection();
<liangjun>return pResult;
<liangjun>}
<mhu>no, that is completely useless, as it is already done that way.
<mhu>and of course, malloc() itself is already thread-safe.
<mhu>i.e. this is not needed at all
<liangjun>mhu: oh
<mhu>btw. what is osl_enter|leaveMemorySection() ? I dont know these functions ?
<mhu>Enter|LeaveCriticalSection(LPCRITICALSECTION s) ?
<mhu>your own invention ?
<liangjun>mhu: yes, It like it
<mhu>okay, but as I said, all of this is already done, either in rtl_allocateMemory() or in the std libc malloc() implementation.
<mhu>and, believe me, I have implemented sal/rtl/source/alloc_global.c, alloc_cache.c and alloc_arena.c :-)
<liangjun>mhu: okey, :)
<mhu>there are very many threading problems in OOo, but just *not* in functions osl_incrementInterlockedCount() and rtl_allocateMemory(). these are probably the best examples of thread safe code :-)
<liangjun>mhu: I think so, but there are all null pointer. So I do it . :)
<mhu>then we probably need to find out where these null pointers come from; they cannot come directly from rtl_allocateMemory(), except you are out of memory already.
<liangjun>yes
<mhu>okay, I read your wiki page, and come back to you.
<liangjun>tools::Container ? and svarray ?
<mhu>they are not protected internally, but access to them need be protected externally.
<liangjun>oh
<mhu>...as with std::vector<T> et al.
<mhu>...none of these basic containers (or strings for that matter, std::string) is protected internally. at least for performance reasons. access must always be synchronized externally.
<liangjun>thank you.
<mhu>...and to make life easy for "old" code, the "SolarMutex" was invented, protecting on a very coarse grain the "old" code.
<mhu>...and everyone can assume that the "SolarMutex" is already hold when they are called.
<mhu>but again, let me read your wiki page, first.
<liangjun>:) okey.
<mhu>...and now I am exhausted :-)
<mhu>...and don't have more for today.
<LiHeng>okay that's all today. Thanks
<liangjun>:) Thanks you.
<mhu>okay, see you next week. have a nice weekend, bye all
<LiHeng>See you next week, have a nice weekend end. bye
<liangjun>bye
Performance/Meetings/2010/05/07
Meeting Minutes
IRC Meeting of ORACLE with RedOffice
Performance Project
Date: 2010/05/07
Agenda:
<mhu>Hi all
<yujinliang>hi
<liangjun>mhu: hi
<LiHeng>hi, mhu
<mhu>Hi LiHeng, liangjun
<LiHeng>Let's update our status
<mhu>hi yujinliang
<yujinliang>hi mhu
<liangjun>mhu:LiHeng: these week, I'd update my source code to m77, and had update to http://hg.services.openoffice.org/cws/loadofd
<mhu>liangjun: could you push your changes to hg.services... ? the server was down for most of the week, I thought.
<LiHeng>My status:Update website of Benchmark-system to alert some information and number when performance has a big change
<liangjun>mhu: yes ,I push my changes today. :)
<mhu>liangjun: ah, okay, that explains it :-)
<yujinliang>sorry , i must leave for some other things
<LiHeng>My status 2: To work on partly loading, try to move my code into a import filter extension.
<mhu>do you somehow synchronize your work of partly loading and parallel loading ?
<liangjun>:) , now the source can compile. but now It has some warning.
<mhu>liangjun: okay ... have you already tested your code ? (and can you fix the warnings ?)
<LiHeng>Yujinliang need to change his station in our office, today. :)
<liangjun>I'm fixing the error. It can't work right.
<LiHeng>mhu: How about the help code of benchmark in tools?
<mhu>liheng: good question, I'm sorry that I did not yet manage to actually review the code; as I said, I am somewhat busy with (internal sun/oracle integration) task, mainly and have not so much time left. But I will sometime look into it.
<LiHeng>No problem, :), but I think I can work out some reports on OOo3.2 to test our system:)
<liangjun>Sorry, I do't fix the synchronization of the ODF parallel load. and I don't know more other module.
<liangjun>I can't know it is debug or designs error. I wish some helper and advise:). of couse I will try to find and fix the error.
<LiHeng>Okay,that all for me. It's jumbled that many people need to change their station now.
<mhu>liangjun: sorry, I was not clear: I was asking whether you and Li Heng sychronize the work that each of you do, one work on parallel loading, the other one on partial loading; do you have a common plan how the result of loading should look like?
<mhu>liangjun: I try to look into loadofd cws, when I find some time, and see whether I can help to debug problems.
<LiHeng>different respects of loading
<LiHeng>zengliangjun has been working on parallel processing document object when a document loading
<LiHeng>and I am working on partly loading , that a function can parse and process the document object that render functions need to get
<mhu>LiHeng: yes, understood. you work on different aspects, but what happens when both your changes are integrated? i.e. both cws integrated, do we have partial and parallel loading then?
<liangjun>mhu: thank you. I wish you can help me check my design is right or no. I do't finish the package and linux implement. So you can't debug directly.
<mhu>liangjun: multithreading sometimes can be debuggged best with pencil and paper (i.e. check and verify the design)
<mhu>...and with code reviews.
<LiHeng>maybe both, but at first i think we can choose the better one to integrate into OOo
<LiHeng>Because, parallel loading maybe have more advantages if we know which document objects need to be parallel :)
<liangjun>LiHeng:mhu: Yes, I wish you can reviews my code simple. the implement is right or no :)
<liangjun>It can't work right sometimes and error sometimes. :)
<mhu>LiHeng: okay, understood. yes, maybe we first need to test the tow aspects, and decide then which is better.
<liangjun>It is the main thing is I can't find the problem, and fix it.
<mhu>liangjun: I try to find / make some time for code reviews.
<liangjun>mhu: thank you.
<LiHeng>mhu: Thanks, you are very kind!
<mhu>liangjun: you're welcome
<liangjun>:)
<mhu>okay, I also don't have more for today; except that we have a public holiday next Thursday, and I have a day vacation on Friday also. So, maybe we can have no meeting next week.
<mhu>...so that I have a long weekend from Thursday to Sunday next week.
<liangjun>Okay,that all for me.
<mhu>LiHeng: so, shall we finish for today ?
<liangjun>mhu: yes
<mhu>liangjun: LiHeng already disconnected ?
<liangjun>He maybe have some problems with network.
<mhu>okay, then bye all, and have a nice weekend; see you in two weeks, May 21.
<liangjun>okay :)
