Re: [castor-dev] GSOC – Self-Introduction an d an initial proposal for "Refactor lock engine "

Ralf Joachim <[email protected]> Mon, 21 Mar 2011 21:08:13 +0100
Newsgroups gmane.comp.java.castor.devel
Organization Syscon Ingenieurbüro GmbH
Message-ID <[email protected]>
Hi Wensheng Dou,

we appreciate your interest in this challenging project idea. The first
draft of your proposal looks quite promising. I'll contact you by
private mail within a few days to discuss your ideas.

Regards
Ralf

Am 21.03.2011 15:42, schrieb =E7=AA=A6=E6=96=87=E7=94=9F:
> Hi Ralf, and all
>
> My name is Wensheng Dou, and I am a first-year Ph.D. student from
> Institute of Software, Chinese Academy of Sciences in China. I am
> interested in parallel and concurrent programming including programming
> models, tool support, especially, refactoring for concurrency in Java.
> And I want to get some practical experience about concurrency-aware
> refactoring.
>
> So I want to get involved in the GSoC2010 and contribute to open source
> project, and I am interested in =E2=80=9CRefactor lock engine=E2=80=9D =
project. I think
> this project could make me gain practical experience, and make Castor
> more scalable, readable and maintainable, and gain good performance.
>
> I have downloaded the Castor code (version 1.3.1, because the main
> version does not work now, because of a maven build error), and I find
> that Castor doesn=E2=80=99t use the java.util.concurrent library to imp=
rove the
> performance (it uses some code from EDU.oswego.cs.dl.util.concurrent
> library). The java.util.concurrent library provides flexible locking
> constructs, more concurrent mechanism, and many lock-free and
> thread-safe atomic data type. The java.util.concurrent library is very
> useful to construct concurrent programs. I think Castor will benefit
> from java.util.concurrent library.
>
> I've read some documentations and some of the code of Castor and as per
> my understanding, the outcomes of the project consists of the following=
s:
>
> 1. Remove the EDU.oswego.cs.dl.util.concurrent library, and use the
> java.util.concurrent library to improve concurrency.
> 2. Find the shared data from the whole Castor project, and use atomic
> data type or correct locks to protect them, and make the program
> behavior-preserving, scalable.
> 3. Find the concurrency bugs in Castor JIRA, and repair these bugs.
>
> After this project is done, Castor will use the java.util.concurrent
> library to provide good performance, and I=E2=80=99ll gain more practic=
e, which
> will help me do my research.
>
> I=E2=80=99ll investigate this project more deeply, and provide a more d=
etailed
> proposal for this project later.
>
> Any comments and suggestions are welcome.
> Thanks in advance for your feedback.
>
>
> Best Regards,
> Wensheng Dou
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
--=20

Syscon Ingenieurb=C3=BCro f=C3=BCr Me=C3=9F- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstra=C3=9Fe 11
72127 Kusterdingen
Germany

Tel.   +49 7071 3690 52
Mobil: +49 173 9630135
Fax    +49 7071 3690 98

Internet: www.syscon.eu
E-Mail: [email protected]

Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Gesch=C3=A4ftsleitung: Jens Joachim, Ralf Joachim


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email