Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [CDO][0.8.0] Thread Safe - hanging problems
|
| Re: [CDO][0.8.0] Thread Safe - hanging problems [message #94920 is a reply to message #94903] |
Thu, 30 August 2007 05:27   |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
This is a multi-part message in MIME format.
--------------090507060303030202050003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Simon McDuff schrieb:
> All the following operations are not thread safe.. Right?
The operations (assignment of HashMap) are thread safe because they
happen during construction time of their containing instance.
I guess you mean that subsequent operations on the maps are not thread safe?
....
> CDORevisionResolverImpl
> private Map<CDOID, TimeLine> revisions = new HashMap();
First I thought this one is thread safe because it is protected by the
internal semantics of ITransaction.
A CDORevision itself is immutable once created so there's no danger.
But now I'm not sure if it could come to problems due to the internal
mechanics of HashMap.
Maybe it'd be better to use a ConcurrentHashMap for
CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue as super
class of TimeLine.
> CDOViewImpl
> private Map<CDOID, InternalCDOObject> objects = new HashMap();
A CDOView is not thread safe by definition.
It shall only be used by a single thread because it contains a
ResourceSet with Resources with EObjects and EObjects are not thread
safe by default (Ed?).
Even EModelElements are only read-only thread safe
( http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html).
Basically I believe that the root cause is somewhere in Net4j rather
than in CDO.
I have more comments in https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366
Cheers
/Eike
--------------090507060303030202050003
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Simon McDuff schrieb:
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.6000.16525" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">All the following operations <font
face="Arial" size="2">are not thread safe.. Right?</font></font></div>
</blockquote>
The operations (assignment of HashMap) are thread safe because they
happen during construction time of their containing instance.<br>
I guess you mean that subsequent operations on the maps are not thread
safe?<br>
....<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDORevisionResolverImpl</font></div>
<div><font face="Arial" size="2">private Map<CDOID, TimeLine>
revisions = new HashMap();</font></div>
</blockquote>
First I thought this one is thread safe because it is protected by the
internal semantics of ITransaction.<br>
A CDORevision itself is immutable once created so there's no danger.<br>
But now I'm not sure if it could come to problems due to the internal
mechanics of HashMap.<br>
Maybe it'd be better to use a ConcurrentHashMap for <font face="Arial"
size="2">CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue
as super class of TimeLine</font>.<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDOViewImpl </font></div>
<div><font face="Arial" size="2">private Map<CDOID,
InternalCDOObject> objects = new HashMap();</font></div>
</blockquote>
A CDOView is not thread safe by definition.<br>
It shall only be used by a single thread because it contains a
ResourceSet with Resources with EObjects and EObjects are not thread
safe by default (Ed?).<br>
Even EModelElements are only read-only thread safe
(<a class="moz-txt-link-freetext" href=" http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html"> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html</a>).<br>
<br>
Basically I believe that the root cause is somewhere in Net4j rather
than in CDO.<br>
I have more comments in
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366">https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366</a><br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
</body>
</html>
--------------090507060303030202050003--
|
|
|
| Re: [CDO][0.8.0] Thread Safe - hanging problems [message #94935 is a reply to message #94920] |
Thu, 30 August 2007 05:38 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
This is a multi-part message in MIME format.
--------------090606060501000402050104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
.... another reason why I don't bellive that missing sync on the maps is
not the cause for the deadlocks is the following:
I believe that in general too few sync *can* cause problems like data
corruption and subsequent failure but deadlock is more likely to occur
with too much or wrong sync.
Cheers
/Eike
Eike Stepper schrieb:
> Simon McDuff schrieb:
>> All the following operations are not thread safe.. Right?
> The operations (assignment of HashMap) are thread safe because they
> happen during construction time of their containing instance.
> I guess you mean that subsequent operations on the maps are not thread
> safe?
> ....
>
>> CDORevisionResolverImpl
>> private Map<CDOID, TimeLine> revisions = new HashMap();
> First I thought this one is thread safe because it is protected by the
> internal semantics of ITransaction.
> A CDORevision itself is immutable once created so there's no danger.
> But now I'm not sure if it could come to problems due to the internal
> mechanics of HashMap.
> Maybe it'd be better to use a ConcurrentHashMap for
> CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue as super
> class of TimeLine.
>
>> CDOViewImpl
>> private Map<CDOID, InternalCDOObject> objects = new HashMap();
> A CDOView is not thread safe by definition.
> It shall only be used by a single thread because it contains a
> ResourceSet with Resources with EObjects and EObjects are not thread
> safe by default (Ed?).
> Even EModelElements are only read-only thread safe
> ( http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html).
>
> Basically I believe that the root cause is somewhere in Net4j rather
> than in CDO.
> I have more comments in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366
>
> Cheers
> /Eike
>
>
--------------090606060501000402050104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
.... another reason why I don't bellive that missing sync on the maps is
not the cause for the deadlocks is the following:<br>
I believe that in general too few sync *can* cause problems like data
corruption and subsequent failure but deadlock is more likely to occur
with too much or wrong sync.<br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
Eike Stepper schrieb:
<blockquote cite="mid:fb5kgk$sri$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Simon McDuff schrieb:
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.6000.16525" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">All the following operations <font
face="Arial" size="2">are not thread safe.. Right?</font></font></div>
</blockquote>
The operations (assignment of HashMap) are thread safe because they
happen during construction time of their containing instance.<br>
I guess you mean that subsequent operations on the maps are not thread
safe?<br>
.....<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDORevisionResolverImpl</font></div>
<div><font face="Arial" size="2">private Map<CDOID, TimeLine>
revisions = new HashMap();</font></div>
</blockquote>
First I thought this one is thread safe because it is protected by the
internal semantics of ITransaction.<br>
A CDORevision itself is immutable once created so there's no danger.<br>
But now I'm not sure if it could come to problems due to the internal
mechanics of HashMap.<br>
Maybe it'd be better to use a ConcurrentHashMap for <font face="Arial"
size="2">CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue
as super class of TimeLine</font>.<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDOViewImpl </font></div>
<div><font face="Arial" size="2">private Map<CDOID,
InternalCDOObject> objects = new HashMap();</font></div>
</blockquote>
A CDOView is not thread safe by definition.<br>
It shall only be used by a single thread because it contains a
ResourceSet with Resources with EObjects and EObjects are not thread
safe by default (Ed?).<br>
Even EModelElements are only read-only thread safe
(<a moz-do-not-send="true" class="moz-txt-link-freetext"
href=" http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html"> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html</a>).<br>
<br>
Basically I believe that the root cause is somewhere in Net4j rather
than in CDO.<br>
I have more comments in
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366">https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366</a><br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
</blockquote>
</body>
</html>
--------------090606060501000402050104--
|
|
| |
| Re: [CDO][0.8.0] Thread Safe - hanging problems [message #94979 is a reply to message #94920] |
Thu, 30 August 2007 11:57 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------020604010706030100090106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Eike,
One example I often give when people ask about thread safety is to
consider the following code applied to a thread safe list.
int index = list.indexOf(x);
list.remove(index);
Even though the list might well be thread safe, this code isn't. So
generally, even if everything you use is thread safe, that doesn't mean
your higher level algorithms will be thread safe. Any code that changes
the state of a complex model will require higher level concurrency control.
I often tell people to consider as well what would happen if we put
synchronized on every method. Not only wouldn't that solve all life's
threading problems, it would in fact be more than likely to cause new
ones, i.e., deadlock.
So all that pontificating aside, EMF models are generally read-only
thread safe, but since demand loading of proxies effectively changes the
state of a model, even things you think involve read only access might
well do more. Ecore itself is designed to be read-only thread safe.
And of course the above aren't a reason to throw up your hands. There
are definitely places where you will need to ensure that something is
done safely because the method being called really is intended to
support more than one thread calling it at once.
Eike Stepper wrote:
> Simon McDuff schrieb:
>> All the following operations are not thread safe.. Right?
> The operations (assignment of HashMap) are thread safe because they
> happen during construction time of their containing instance.
> I guess you mean that subsequent operations on the maps are not thread
> safe?
> ...
>
>> CDORevisionResolverImpl
>> private Map<CDOID, TimeLine> revisions = new HashMap();
> First I thought this one is thread safe because it is protected by the
> internal semantics of ITransaction.
> A CDORevision itself is immutable once created so there's no danger.
> But now I'm not sure if it could come to problems due to the internal
> mechanics of HashMap.
> Maybe it'd be better to use a ConcurrentHashMap for
> CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue as super
> class of TimeLine.
>
>> CDOViewImpl
>> private Map<CDOID, InternalCDOObject> objects = new HashMap();
> A CDOView is not thread safe by definition.
> It shall only be used by a single thread because it contains a
> ResourceSet with Resources with EObjects and EObjects are not thread
> safe by default (Ed?).
> Even EModelElements are only read-only thread safe
> ( http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html).
>
> Basically I believe that the root cause is somewhere in Net4j rather
> than in CDO.
> I have more comments in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366
>
> Cheers
> /Eike
>
>
--------------020604010706030100090106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Eike,<br>
<br>
One example I often give when people ask about thread safety is to
consider the following code applied to a thread safe list.<br>
<blockquote>int index = list.indexOf(x);<br>
list.remove(index);<br>
</blockquote>
Even though the list might well be thread safe, this code isn't. So
generally, even if everything you use is thread safe, that doesn't mean
your higher level algorithms will be thread safe. Any code that
changes the state of a complex model will require higher level
concurrency control.<br>
<br>
I often tell people to consider as well what would happen if we put
synchronized on every method. Not only wouldn't that solve all life's
threading problems, it would in fact be more than likely to cause new
ones, i.e., deadlock.<br>
<br>
So all that pontificating aside, EMF models are generally read-only
thread safe, but since demand loading of proxies effectively changes
the state of a model, even things you think involve read only access
might well do more. Ecore itself is designed to be read-only thread
safe. And of course the above aren't a reason to throw up your hands.
There are definitely places where you will need to ensure that
something is done safely because the method being called really is
intended to support more than one thread calling it at once.<br>
<br>
<br>
Eike Stepper wrote:
<blockquote cite="mid:fb5kgk$sri$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Simon McDuff schrieb:
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.6000.16525" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">All the following operations <font
face="Arial" size="2">are not thread safe.. Right?</font></font></div>
</blockquote>
The operations (assignment of HashMap) are thread safe because they
happen during construction time of their containing instance.<br>
I guess you mean that subsequent operations on the maps are not thread
safe?<br>
....<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDORevisionResolverImpl</font></div>
<div><font face="Arial" size="2">private Map<CDOID, TimeLine>
revisions = new HashMap();</font></div>
</blockquote>
First I thought this one is thread safe because it is protected by the
internal semantics of ITransaction.<br>
A CDORevision itself is immutable once created so there's no danger.<br>
But now I'm not sure if it could come to problems due to the internal
mechanics of HashMap.<br>
Maybe it'd be better to use a ConcurrentHashMap for <font face="Arial"
size="2">CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue
as super class of TimeLine</font>.<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDOViewImpl </font></div>
<div><font face="Arial" size="2">private Map<CDOID,
InternalCDOObject> objects = new HashMap();</font></div>
</blockquote>
A CDOView is not thread safe by definition.<br>
It shall only be used by a single thread because it contains a
ResourceSet with Resources with EObjects and EObjects are not thread
safe by default (Ed?).<br>
Even EModelElements are only read-only thread safe
(<a moz-do-not-send="true" class="moz-txt-link-freetext"
href=" http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html"> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html</a>).<br>
<br>
Basically I believe that the root cause is somewhere in Net4j rather
than in CDO.<br>
I have more comments in
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366">https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366</a><br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>
--------------020604010706030100090106--
|
|
|
| Re: [CDO][0.8.0] Thread Safe - hanging problems [message #95012 is a reply to message #94979] |
Thu, 30 August 2007 12:13 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
This is a multi-part message in MIME format.
--------------080905090106060702000003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Ed,
It's clear to me that I have to protect subsequent accesses to a thread
safe data structure, for example:
synchronized (revisions)
{
TimeLine timeLine = revisions.get(id);
if (timeLine == null)
{
timeLine = new TimeLine(id);
revisions.put(id, timeLine);
}
return timeLine;
}
But if the used data structure is not thread safe in itself two threads
could mess it up with a single access each.
A HashMap.put() for example could cause rehashing while another thread
is trying to access the map.
Cheers
/Eike
Ed Merks schrieb:
> Eike,
>
> One example I often give when people ask about thread safety is to
> consider the following code applied to a thread safe list.
>
> int index = list.indexOf(x);
> list.remove(index);
>
> Even though the list might well be thread safe, this code isn't. So
> generally, even if everything you use is thread safe, that doesn't
> mean your higher level algorithms will be thread safe. Any code that
> changes the state of a complex model will require higher level
> concurrency control.
>
> I often tell people to consider as well what would happen if we put
> synchronized on every method. Not only wouldn't that solve all life's
> threading problems, it would in fact be more than likely to cause new
> ones, i.e., deadlock.
>
> So all that pontificating aside, EMF models are generally read-only
> thread safe, but since demand loading of proxies effectively changes
> the state of a model, even things you think involve read only access
> might well do more. Ecore itself is designed to be read-only thread
> safe. And of course the above aren't a reason to throw up your
> hands. There are definitely places where you will need to ensure that
> something is done safely because the method being called really is
> intended to support more than one thread calling it at once.
>
>
> Eike Stepper wrote:
>> Simon McDuff schrieb:
>>> All the following operations are not thread safe.. Right?
>> The operations (assignment of HashMap) are thread safe because they
>> happen during construction time of their containing instance.
>> I guess you mean that subsequent operations on the maps are not
>> thread safe?
>> ....
>>
>>> CDORevisionResolverImpl
>>> private Map<CDOID, TimeLine> revisions = new HashMap();
>> First I thought this one is thread safe because it is protected by
>> the internal semantics of ITransaction.
>> A CDORevision itself is immutable once created so there's no danger.
>> But now I'm not sure if it could come to problems due to the internal
>> mechanics of HashMap.
>> Maybe it'd be better to use a ConcurrentHashMap for
>> CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue as
>> super class of TimeLine.
>>
>>> CDOViewImpl
>>> private Map<CDOID, InternalCDOObject> objects = new HashMap();
>> A CDOView is not thread safe by definition.
>> It shall only be used by a single thread because it contains a
>> ResourceSet with Resources with EObjects and EObjects are not thread
>> safe by default (Ed?).
>> Even EModelElements are only read-only thread safe
>> ( http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html).
>>
>> Basically I believe that the root cause is somewhere in Net4j rather
>> than in CDO.
>> I have more comments in
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366
>>
>> Cheers
>> /Eike
>>
>>
>
--------------080905090106060702000003
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ed,<br>
<br>
It's clear to me that I have to protect subsequent accesses to a thread
safe data structure, for example:<br>
<br>
synchronized (revisions)<br>
{<br>
TimeLine timeLine = revisions.get(id);<br>
if (timeLine == null)<br>
{<br>
timeLine = new TimeLine(id);<br>
revisions.put(id, timeLine);<br>
}<br>
<br>
return timeLine;<br>
}<br>
<br>
But if the used data structure is not thread safe in itself two threads
could mess it up with a single access each.<br>
A HashMap.put() for example could cause rehashing while another thread
is trying to access the map.<br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
Ed Merks schrieb:
<blockquote cite="mid:fb6b7f$n49$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Eike,<br>
<br>
One example I often give when people ask about thread safety is to
consider the following code applied to a thread safe list.<br>
<blockquote>int index = list.indexOf(x);<br>
list.remove(index);<br>
</blockquote>
Even though the list might well be thread safe, this code isn't. So
generally, even if everything you use is thread safe, that doesn't mean
your higher level algorithms will be thread safe. Any code that
changes the state of a complex model will require higher level
concurrency control.<br>
<br>
I often tell people to consider as well what would happen if we put
synchronized on every method. Not only wouldn't that solve all life's
threading problems, it would in fact be more than likely to cause new
ones, i.e., deadlock.<br>
<br>
So all that pontificating aside, EMF models are generally read-only
thread safe, but since demand loading of proxies effectively changes
the state of a model, even things you think involve read only access
might well do more. Ecore itself is designed to be read-only thread
safe. And of course the above aren't a reason to throw up your hands.
There are definitely places where you will need to ensure that
something is done safely because the method being called really is
intended to support more than one thread calling it at once.<br>
<br>
<br>
Eike Stepper wrote:
<blockquote cite="mid:fb5kgk$sri$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
Simon McDuff schrieb:
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.6000.16525" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">All the following operations <font
face="Arial" size="2">are not thread safe.. Right?</font></font></div>
</blockquote>
The operations (assignment of HashMap) are thread safe because they
happen during construction time of their containing instance.<br>
I guess you mean that subsequent operations on the maps are not thread
safe?<br>
.....<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDORevisionResolverImpl</font></div>
<div><font face="Arial" size="2">private Map<CDOID,
TimeLine>
revisions = new HashMap();</font></div>
</blockquote>
First I thought this one is thread safe because it is protected by the
internal semantics of ITransaction.<br>
A CDORevision itself is immutable once created so there's no danger.<br>
But now I'm not sure if it could come to problems due to the internal
mechanics of HashMap.<br>
Maybe it'd be better to use a ConcurrentHashMap for <font face="Arial"
size="2">CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue
as super class of TimeLine</font>.<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDOViewImpl </font></div>
<div><font face="Arial" size="2">private Map<CDOID,
InternalCDOObject> objects = new HashMap();</font></div>
</blockquote>
A CDOView is not thread safe by definition.<br>
It shall only be used by a single thread because it contains a
ResourceSet with Resources with EObjects and EObjects are not thread
safe by default (Ed?).<br>
Even EModelElements are only read-only thread safe
(<a moz-do-not-send="true" class="moz-txt-link-freetext"
href=" http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html"> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html</a>).<br>
<br>
Basically I believe that the root cause is somewhere in Net4j rather
than in CDO.<br>
I have more comments in <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366">https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366</a><br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
</body>
</html>
--------------080905090106060702000003--
|
|
|
| Re: [CDO][0.8.0] Thread Safe - hanging problems [message #95025 is a reply to message #94964] |
Thu, 30 August 2007 12:14 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
This is a multi-part message in MIME format.
--------------080608000109070005090109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I've added chained synchronization to CDORevisionResolverImpl.
What do you think?
Simon McDuff schrieb:
> Sorry Eike, I wasn't clear enough.. but I thought it was obvious.
>
> Everyone that connect to that repository will go through these
> variable and call
>
>
> TimeLine timeLine = revisions.get(id);
>
> *if* (timeLine == *null*)
>
> {
>
> timeLine = *new* TimeLine(id);
>
> revisions.put(id, timeLine);
>
> }
>
> *return* timeLine;
>
>
>
> We could have a problem there.... everywhere where we use revisions...
> not when we contruct it.
>
> Same thing for other attributs I mention...
>
>
>
>
>
>
> "Eike Stepper" <stepper@sympedia.de <mailto:stepper@sympedia.de>>
> wrote in message news:fb5kgk$sri$1@build.eclipse.org...
> Simon McDuff schrieb:
>> All the following operations are not thread safe.. Right?
> The operations (assignment of HashMap) are thread safe because
> they happen during construction time of their containing instance.
> I guess you mean that subsequent operations on the maps are not
> thread safe?
> ...
>
>> CDORevisionResolverImpl
>> private Map<CDOID, TimeLine> revisions = new HashMap();
> First I thought this one is thread safe because it is protected by
> the internal semantics of ITransaction.
> A CDORevision itself is immutable once created so there's no danger.
> But now I'm not sure if it could come to problems due to the
> internal mechanics of HashMap.
> Maybe it'd be better to use a ConcurrentHashMap for
> CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue as
> super class of TimeLine.
>
>> CDOViewImpl
>> private Map<CDOID, InternalCDOObject> objects = new HashMap();
> A CDOView is not thread safe by definition.
> It shall only be used by a single thread because it contains a
> ResourceSet with Resources with EObjects and EObjects are not
> thread safe by default (Ed?).
> Even EModelElements are only read-only thread safe
> ( http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html).
>
> Basically I believe that the root cause is somewhere in Net4j
> rather than in CDO.
> I have more comments in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366
>
> Cheers
> /Eike
>
>
--------------080608000109070005090109
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I've added chained synchronization to CDORevisionResolverImpl.<br>
What do you think?<br>
<br>
<br>
Simon McDuff schrieb:
<blockquote cite="mid:fb68qk$f43$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<meta content="MSHTML 6.00.2900.3157" name="GENERATOR">
<div><font face="Arial" size="2">Sorry Eike, I wasn't clear enough..
but I thought it was obvious.</font></div>
<div> </div>
<div><font face="Arial" size="2">Everyone that connect to that
repository will go through these variable and call</font></div>
<div> </div>
<div><font size="2">
</font>
<p align="left"><font size="2">TimeLine timeLine = </font><font
color="#0000c0" size="2">revisions</font><font size="2">.get(id);</font></p>
<p align="left"><b><font color="#7f0055" size="2">if</font></b><font
size="2"> (timeLine == </font><b><font color="#7f0055" size="2">null</font></b><font
size="2">)</font></p>
<p align="left"><font size="2">{</font></p>
<p align="left"><font size="2">timeLine = </font><b><font
color="#7f0055" size="2">new</font></b><font size="2"> TimeLine(id);</font></p>
<p align="left"><font color="#0000c0" size="2">revisions</font><font
size="2">.put(id, timeLine);</font></p>
<p align="left"><font size="2">}</font></p>
<p align="left"><b><font color="#7f0055" size="2">return</font></b><font
size="2"> timeLine;</font></p>
<p align="left"> </p>
<p align="left"><font size="2">We could have a problem there....
everywhere where we use <font color="#0000c0">revisions... not when we
contruct it.</font></font></p>
<p align="left"><font size="2"><font face="Arial">Same thing for
other attributs I mention... </font></font></p>
<p align="left"><font size="2"> </font></p>
</div>
<div> </div>
<div> </div>
<blockquote
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div>"Eike Stepper" <<a moz-do-not-send="true"
href="mailto:stepper@sympedia.de">stepper@sympedia.de</a>> wrote in
message <a moz-do-not-send="true"
href="news:fb5kgk$sri$1@build.eclipse.org">news:fb5kgk$sri$1@build.eclipse.org</a>...</div>
Simon McDuff schrieb:
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<meta content="MSHTML 6.00.6000.16525" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">All the following operations <font
face="Arial" size="2">are not thread safe.. Right?</font></font></div>
</blockquote>
The operations (assignment of HashMap) are thread safe because they
happen during construction time of their containing instance.<br>
I guess you mean that subsequent operations on the maps are not thread
safe?<br>
....<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDORevisionResolverImpl</font></div>
<div><font face="Arial" size="2">private Map<CDOID,
TimeLine> revisions = new HashMap();</font></div>
</blockquote>
First I thought this one is thread safe because it is protected by the
internal semantics of ITransaction.<br>
A CDORevision itself is immutable once created so there's no danger.<br>
But now I'm not sure if it could come to problems due to the internal
mechanics of HashMap.<br>
Maybe it'd be better to use a ConcurrentHashMap for <font face="Arial"
size="2">CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue
as super class of TimeLine</font>.<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDOViewImpl </font></div>
<div><font face="Arial" size="2">private Map<CDOID,
InternalCDOObject> objects = new HashMap();</font></div>
</blockquote>
A CDOView is not thread safe by definition.<br>
It shall only be used by a single thread because it contains a
ResourceSet with Resources with EObjects and EObjects are not thread
safe by default (Ed?).<br>
Even EModelElements are only read-only thread safe (<a
moz-do-not-send="true" class="moz-txt-link-freetext"
href=" http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html"> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html</a>).<br>
<br>
Basically I believe that the root cause is somewhere in Net4j rather
than in CDO.<br>
I have more comments in <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366">https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366</a><br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
</blockquote>
</blockquote>
</body>
</html>
--------------080608000109070005090109--
|
|
|
| Re: [CDO][0.8.0] Thread Safe - hanging problems [message #95040 is a reply to message #95025] |
Thu, 30 August 2007 12:32 |
 Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0311_01C7EAE0.564C3FC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
This seems to be well done. But I'm not an expert :-)
It is working with my JCSMap as well !!!!
"Eike Stepper" <stepper@sympedia.de> wrote in message =
news:fb6cak$sri$4@build.eclipse.org...
I've added chained synchronization to CDORevisionResolverImpl.
What do you think?
Simon McDuff schrieb:=20
Sorry Eike, I wasn't clear enough.. but I thought it was obvious.
Everyone that connect to that repository will go through these =
variable and call
TimeLine timeLine =3D revisions.get(id);
if (timeLine =3D=3D null)
{
timeLine =3D new TimeLine(id);
revisions.put(id, timeLine);
}
return timeLine;
We could have a problem there.... everywhere where we use =
revisions... not when we contruct it.
Same thing for other attributs I mention...=20
"Eike Stepper" <stepper@sympedia.de> wrote in message =
news:fb5kgk$sri$1@build.eclipse.org...
Simon McDuff schrieb:=20
All the following operations are not thread safe.. Right?
The operations (assignment of HashMap) are thread safe because =
they happen during construction time of their containing instance.
I guess you mean that subsequent operations on the maps are not =
thread safe?
...
CDORevisionResolverImpl
private Map<CDOID, TimeLine> revisions =3D new HashMap();
First I thought this one is thread safe because it is protected by =
the internal semantics of ITransaction.
A CDORevision itself is immutable once created so there's no =
danger.
But now I'm not sure if it could come to problems due to the =
internal mechanics of HashMap.
Maybe it'd be better to use a ConcurrentHashMap for =
CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue as super =
class of TimeLine.
CDOViewImpl=20
private Map<CDOID, InternalCDOObject> objects =3D new HashMap();
A CDOView is not thread safe by definition.
It shall only be used by a single thread because it contains a =
ResourceSet with Resources with EObjects and EObjects are not thread =
safe by default (Ed?).
Even EModelElements are only read-only thread safe =
( http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html).
Basically I believe that the root cause is somewhere in Net4j =
rather than in CDO.
I have more comments in =
https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D201366
Cheers
/Eike
------=_NextPart_000_0311_01C7EAE0.564C3FC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>This seems to be well done. But I'm not =
an expert=20
:-)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>It is working with my JCSMap as well=20
!!!!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>"Eike Stepper" <<A=20
href=3D"mailto:stepper@sympedia.de">stepper@sympedia.de</A>> wrote in =
message=20
<A=20
href=3D"news:fb6cak$sri$4@build.eclipse.org">news:fb6cak$sri$4@build.ecli=
pse.org</A>...</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">I've=20
added chained synchronization to CDORevisionResolverImpl.<BR>What do =
you=20
think?<BR><BR><BR>Simon McDuff schrieb:=20
<BLOCKQUOTE cite=3Dmid:fb68qk$f43$1@build.eclipse.org type=3D"cite">
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR>
<DIV><FONT face=3DArial size=3D2>Sorry Eike, I wasn't clear enough.. =
but I=20
thought it was obvious.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Everyone that connect to that =
repository will=20
go through these variable and call</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2></FONT>
<P align=3Dleft><FONT size=3D2>TimeLine timeLine =3D </FONT><FONT =
color=3D#0000c0=20
size=3D2>revisions</FONT><FONT size=3D2>.get(id);</FONT></P>
<P align=3Dleft><B><FONT color=3D#7f0055 size=3D2>if</FONT></B><FONT =
size=3D2>=20
(timeLine =3D=3D </FONT><B><FONT color=3D#7f0055 =
size=3D2>null</FONT></B><FONT=20
size=3D2>)</FONT></P>
<P align=3Dleft><FONT size=3D2>{</FONT></P>
<P align=3Dleft><FONT size=3D2>timeLine =3D </FONT><B><FONT =
color=3D#7f0055=20
size=3D2>new</FONT></B><FONT size=3D2> TimeLine(id);</FONT></P>
<P align=3Dleft><FONT color=3D#0000c0 size=3D2>revisions</FONT><FONT =
size=3D2>.put(id, timeLine);</FONT></P>
<P align=3Dleft><FONT size=3D2>}</FONT></P>
<P align=3Dleft><B><FONT color=3D#7f0055 =
size=3D2>return</FONT></B><FONT size=3D2>=20
timeLine;</FONT></P>
<P align=3Dleft> </P>
<P align=3Dleft><FONT size=3D2>We could have a problem there.... =
everywhere=20
where we use <FONT color=3D#0000c0>revisions... not when we contruct =
it.</FONT></FONT></P>
<P align=3Dleft><FONT size=3D2><FONT face=3DArial>Same thing for =
other attributs I=20
mention... </FONT></FONT></P>
<P align=3Dleft><FONT size=3D2></FONT> </P></DIV>
<DIV> </DIV>
<DIV> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: rgb(0,0,0) 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Eike Stepper" <<A href=3D"mailto:stepper@sympedia.de"=20
moz-do-not-send=3D"true">stepper@sympedia.de</A>> wrote in =
message <A=20
href=3D"news:fb5kgk$sri$1@build.eclipse.org"=20
=
moz-do-not-send=3D"true">news:fb5kgk$sri$1@build.eclipse.org</A>...</DIV>=
Simon=20
McDuff schrieb:=20
<BLOCKQUOTE cite=3Dmid:fb542f$90d$1@build.eclipse.org =
type=3D"cite">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
<DIV><FONT face=3DArial size=3D2>All the following =
operations <FONT=20
face=3DArial size=3D2>are not thread safe..=20
Right?</FONT></FONT></DIV></BLOCKQUOTE>The operations (assignment =
of=20
HashMap) are thread safe because they happen during construction =
time of=20
their containing instance.<BR>I guess you mean that subsequent =
operations=20
on the maps are not thread safe?<BR>...<BR><BR>
<BLOCKQUOTE cite=3Dmid:fb542f$90d$1@build.eclipse.org =
type=3D"cite">
<DIV><FONT face=3DArial =
size=3D2>CDORevisionResolverImpl</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>private Map<CDOID, =
TimeLine>=20
revisions =3D new HashMap();</FONT></DIV></BLOCKQUOTE>First I =
thought this=20
one is thread safe because it is protected by the internal =
semantics of=20
ITransaction.<BR>A CDORevision itself is immutable once created so =
there's=20
no danger.<BR>But now I'm not sure if it could come to problems =
due to the=20
internal mechanics of HashMap.<BR>Maybe it'd be better to use a=20
ConcurrentHashMap for <FONT face=3DArial=20
size=3D2>CDORevisionResolverImpl.revisions and a =
ConcurrentLinkedQueue as=20
super class of TimeLine</FONT>.<BR><BR>
<BLOCKQUOTE cite=3Dmid:fb542f$90d$1@build.eclipse.org =
type=3D"cite">
<DIV><FONT face=3DArial size=3D2>CDOViewImpl </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>private Map<CDOID, =
InternalCDOObject>=20
objects =3D new HashMap();</FONT></DIV></BLOCKQUOTE>A CDOView is =
not thread=20
safe by definition.<BR>It shall only be used by a single thread =
because it=20
contains a ResourceSet with Resources with EObjects and EObjects =
are not=20
thread safe by default (Ed?).<BR>Even EModelElements are only =
read-only=20
thread safe (<A class=3Dmoz-txt-link-freetext=20
=
href=3D" http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.=
html"=20
=
moz-do-not-send=3D"true">http://dev.eclipse.org/newslists/news.eclipse.to=
ols.emf/msg26143.html</A>).<BR><BR>Basically=20
I believe that the root cause is somewhere in Net4j rather than in =
CDO.<BR>I have more comments in <A class=3Dmoz-txt-link-freetext=20
href=3D"https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D201366"=20
=
moz-do-not-send=3D"true">https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D=
201366</A><BR><BR>Cheers<BR>/Eike<BR><BR><BR></BLOCKQUOTE ></BLOCKQUOTE></=
BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0311_01C7EAE0.564C3FC0--
|
|
|
| Re: [CDO][0.8.0] Thread Safe - hanging problems [message #95055 is a reply to message #95012] |
Thu, 30 August 2007 14:35 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------000807020602010305060601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Eike,
Yes, this is definitely a case where you need to synchronize properly.
Eike Stepper wrote:
> Ed,
>
> It's clear to me that I have to protect subsequent accesses to a
> thread safe data structure, for example:
>
> synchronized (revisions)
> {
> TimeLine timeLine = revisions.get(id);
> if (timeLine == null)
> {
> timeLine = new TimeLine(id);
> revisions.put(id, timeLine);
> }
>
> return timeLine;
> }
>
> But if the used data structure is not thread safe in itself two
> threads could mess it up with a single access each.
> A HashMap.put() for example could cause rehashing while another thread
> is trying to access the map.
>
> Cheers
> /Eike
>
>
> Ed Merks schrieb:
>> Eike,
>>
>> One example I often give when people ask about thread safety is to
>> consider the following code applied to a thread safe list.
>>
>> int index = list.indexOf(x);
>> list.remove(index);
>>
>> Even though the list might well be thread safe, this code isn't. So
>> generally, even if everything you use is thread safe, that doesn't
>> mean your higher level algorithms will be thread safe. Any code that
>> changes the state of a complex model will require higher level
>> concurrency control.
>>
>> I often tell people to consider as well what would happen if we put
>> synchronized on every method. Not only wouldn't that solve all
>> life's threading problems, it would in fact be more than likely to
>> cause new ones, i.e., deadlock.
>>
>> So all that pontificating aside, EMF models are generally read-only
>> thread safe, but since demand loading of proxies effectively changes
>> the state of a model, even things you think involve read only access
>> might well do more. Ecore itself is designed to be read-only thread
>> safe. And of course the above aren't a reason to throw up your
>> hands. There are definitely places where you will need to ensure
>> that something is done safely because the method being called really
>> is intended to support more than one thread calling it at once.
>>
>>
>> Eike Stepper wrote:
>>> Simon McDuff schrieb:
>>>> All the following operations are not thread safe.. Right?
>>> The operations (assignment of HashMap) are thread safe because they
>>> happen during construction time of their containing instance.
>>> I guess you mean that subsequent operations on the maps are not
>>> thread safe?
>>> ....
>>>
>>>> CDORevisionResolverImpl
>>>> private Map<CDOID, TimeLine> revisions = new HashMap();
>>> First I thought this one is thread safe because it is protected by
>>> the internal semantics of ITransaction.
>>> A CDORevision itself is immutable once created so there's no danger.
>>> But now I'm not sure if it could come to problems due to the
>>> internal mechanics of HashMap.
>>> Maybe it'd be better to use a ConcurrentHashMap for
>>> CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue as
>>> super class of TimeLine.
>>>
>>>> CDOViewImpl
>>>> private Map<CDOID, InternalCDOObject> objects = new HashMap();
>>> A CDOView is not thread safe by definition.
>>> It shall only be used by a single thread because it contains a
>>> ResourceSet with Resources with EObjects and EObjects are not thread
>>> safe by default (Ed?).
>>> Even EModelElements are only read-only thread safe
>>> ( http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html).
>>>
>>> Basically I believe that the root cause is somewhere in Net4j rather
>>> than in CDO.
>>> I have more comments in
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>
--------------000807020602010305060601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Eike,<br>
<br>
Yes, this is definitely a case where you need to synchronize properly.<br>
<br>
<br>
Eike Stepper wrote:
<blockquote cite="mid:fb6c86$sri$3@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Ed,<br>
<br>
It's clear to me that I have to protect subsequent accesses to a thread
safe data structure, for example:<br>
<br>
synchronized (revisions)<br>
{<br>
TimeLine timeLine = revisions.get(id);<br>
if (timeLine == null)<br>
{<br>
timeLine = new TimeLine(id);<br>
revisions.put(id, timeLine);<br>
}<br>
<br>
return timeLine;<br>
}<br>
<br>
But if the used data structure is not thread safe in itself two threads
could mess it up with a single access each.<br>
A HashMap.put() for example could cause rehashing while another thread
is trying to access the map.<br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
Ed Merks schrieb:
<blockquote cite="mid:fb6b7f$n49$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
Eike,<br>
<br>
One example I often give when people ask about thread safety is to
consider the following code applied to a thread safe list.<br>
<blockquote>int index = list.indexOf(x);<br>
list.remove(index);<br>
</blockquote>
Even though the list might well be thread safe, this code isn't. So
generally, even if everything you use is thread safe, that doesn't mean
your higher level algorithms will be thread safe. Any code that
changes the state of a complex model will require higher level
concurrency control.<br>
<br>
I often tell people to consider as well what would happen if we put
synchronized on every method. Not only wouldn't that solve all life's
threading problems, it would in fact be more than likely to cause new
ones, i.e., deadlock.<br>
<br>
So all that pontificating aside, EMF models are generally read-only
thread safe, but since demand loading of proxies effectively changes
the state of a model, even things you think involve read only access
might well do more. Ecore itself is designed to be read-only thread
safe. And of course the above aren't a reason to throw up your hands.
There are definitely places where you will need to ensure that
something is done safely because the method being called really is
intended to support more than one thread calling it at once.<br>
<br>
<br>
Eike Stepper wrote:
<blockquote cite="mid:fb5kgk$sri$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
Simon McDuff schrieb:
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.6000.16525" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">All the following operations <font
face="Arial" size="2">are not thread safe.. Right?</font></font></div>
</blockquote>
The operations (assignment of HashMap) are thread safe because they
happen during construction time of their containing instance.<br>
I guess you mean that subsequent operations on the maps are not thread
safe?<br>
.....<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDORevisionResolverImpl</font></div>
<div><font face="Arial" size="2">private Map<CDOID,
TimeLine>
revisions = new HashMap();</font></div>
</blockquote>
First I thought this one is thread safe because it is protected by the
internal semantics of ITransaction.<br>
A CDORevision itself is immutable once created so there's no danger.<br>
But now I'm not sure if it could come to problems due to the internal
mechanics of HashMap.<br>
Maybe it'd be better to use a ConcurrentHashMap for <font face="Arial"
size="2">CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue
as super class of TimeLine</font>.<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDOViewImpl </font></div>
<div><font face="Arial" size="2">private Map<CDOID,
InternalCDOObject> objects = new HashMap();</font></div>
</blockquote>
A CDOView is not thread safe by definition.<br>
It shall only be used by a single thread because it contains a
ResourceSet with Resources with EObjects and EObjects are not thread
safe by default (Ed?).<br>
Even EModelElements are only read-only thread safe
(<a moz-do-not-send="true" class="moz-txt-link-freetext"
href=" http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html"> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html</a>).<br>
<br>
Basically I believe that the root cause is somewhere in Net4j rather
than in CDO.<br>
I have more comments in <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366">https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366</a><br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------000807020602010305060601--
|
|
|
| Re: [CDO][0.8.0] Thread Safe - hanging problems [message #95070 is a reply to message #95040] |
Thu, 30 August 2007 14:49 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
This is a multi-part message in MIME format.
--------------050408050200070208000101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Simon McDuff schrieb:
> This seems to be well done. But I'm not an expert :-)
> It is working with my JCSMap as well !!!!
Cool!!! I'm happy that it's solved and sorry for the inconvenience.
Maybe in the future when we recognize that too many threads are being
allocated we are brave enough to give AsynchronousWorkSerializer another
try ;-)
BTW. I've added the following to Channel.doDeactivate()
if (receiveSerializer != null)
{
receiveSerializer.dispose();
receiveSerializer = null;
}
Cheers
/Eike
--------------050408050200070208000101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Simon McDuff schrieb:
<blockquote cite="mid:fb6ddd$i4i$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<meta content="MSHTML 6.00.2900.3157" name="GENERATOR">
<div><font face="Arial" size="2">This seems to be well done. But I'm
not an expert :-)</font></div>
<div><font face="Arial" size="2">It is working with my JCSMap as well
!!!!</font></div>
</blockquote>
Cool!!! I'm happy that it's solved and sorry for the inconvenience.<br>
Maybe in the future when we recognize that too many threads are being
allocated we are brave enough to give AsynchronousWorkSerializer
another try ;-)<br>
<br>
BTW. I've added the following to Channel.doDeactivate()<br>
<br>
if (receiveSerializer != null)<br>
{<br>
receiveSerializer.dispose();<br>
receiveSerializer = null;<br>
}<br>
<br>
Cheers<br>
/Eike<br>
<br>
</body>
</html>
--------------050408050200070208000101--
|
|
|
| Re: [CDO][0.8.0] Thread Safe - hanging problems [message #609582 is a reply to message #94903] |
Thu, 30 August 2007 05:27 |
|
This is a multi-part message in MIME format.
--------------090507060303030202050003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Simon McDuff schrieb:
> All the following operations are not thread safe.. Right?
The operations (assignment of HashMap) are thread safe because they
happen during construction time of their containing instance.
I guess you mean that subsequent operations on the maps are not thread safe?
....
> CDORevisionResolverImpl
> private Map<CDOID, TimeLine> revisions = new HashMap();
First I thought this one is thread safe because it is protected by the
internal semantics of ITransaction.
A CDORevision itself is immutable once created so there's no danger.
But now I'm not sure if it could come to problems due to the internal
mechanics of HashMap.
Maybe it'd be better to use a ConcurrentHashMap for
CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue as super
class of TimeLine.
> CDOViewImpl
> private Map<CDOID, InternalCDOObject> objects = new HashMap();
A CDOView is not thread safe by definition.
It shall only be used by a single thread because it contains a
ResourceSet with Resources with EObjects and EObjects are not thread
safe by default (Ed?).
Even EModelElements are only read-only thread safe
( http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html).
Basically I believe that the root cause is somewhere in Net4j rather
than in CDO.
I have more comments in https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366
Cheers
/Eike
--------------090507060303030202050003
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Simon McDuff schrieb:
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.6000.16525" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">All the following operations <font
face="Arial" size="2">are not thread safe.. Right?</font></font></div>
</blockquote>
The operations (assignment of HashMap) are thread safe because they
happen during construction time of their containing instance.<br>
I guess you mean that subsequent operations on the maps are not thread
safe?<br>
....<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDORevisionResolverImpl</font></div>
<div><font face="Arial" size="2">private Map<CDOID, TimeLine>
revisions = new HashMap();</font></div>
</blockquote>
First I thought this one is thread safe because it is protected by the
internal semantics of ITransaction.<br>
A CDORevision itself is immutable once created so there's no danger.<br>
But now I'm not sure if it could come to problems due to the internal
mechanics of HashMap.<br>
Maybe it'd be better to use a ConcurrentHashMap for <font face="Arial"
size="2">CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue
as super class of TimeLine</font>.<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDOViewImpl </font></div>
<div><font face="Arial" size="2">private Map<CDOID,
InternalCDOObject> objects = new HashMap();</font></div>
</blockquote>
A CDOView is not thread safe by definition.<br>
It shall only be used by a single thread because it contains a
ResourceSet with Resources with EObjects and EObjects are not thread
safe by default (Ed?).<br>
Even EModelElements are only read-only thread safe
(<a class="moz-txt-link-freetext" href=" http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html"> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html</a>).<br>
<br>
Basically I believe that the root cause is somewhere in Net4j rather
than in CDO.<br>
I have more comments in
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366">https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366</a><br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
</body>
</html>
--------------090507060303030202050003--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO][0.8.0] Thread Safe - hanging problems [message #609583 is a reply to message #94920] |
Thu, 30 August 2007 05:38 |
|
This is a multi-part message in MIME format.
--------------090606060501000402050104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
.... another reason why I don't bellive that missing sync on the maps is
not the cause for the deadlocks is the following:
I believe that in general too few sync *can* cause problems like data
corruption and subsequent failure but deadlock is more likely to occur
with too much or wrong sync.
Cheers
/Eike
Eike Stepper schrieb:
> Simon McDuff schrieb:
>> All the following operations are not thread safe.. Right?
> The operations (assignment of HashMap) are thread safe because they
> happen during construction time of their containing instance.
> I guess you mean that subsequent operations on the maps are not thread
> safe?
> ....
>
>> CDORevisionResolverImpl
>> private Map<CDOID, TimeLine> revisions = new HashMap();
> First I thought this one is thread safe because it is protected by the
> internal semantics of ITransaction.
> A CDORevision itself is immutable once created so there's no danger.
> But now I'm not sure if it could come to problems due to the internal
> mechanics of HashMap.
> Maybe it'd be better to use a ConcurrentHashMap for
> CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue as super
> class of TimeLine.
>
>> CDOViewImpl
>> private Map<CDOID, InternalCDOObject> objects = new HashMap();
> A CDOView is not thread safe by definition.
> It shall only be used by a single thread because it contains a
> ResourceSet with Resources with EObjects and EObjects are not thread
> safe by default (Ed?).
> Even EModelElements are only read-only thread safe
> ( http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html).
>
> Basically I believe that the root cause is somewhere in Net4j rather
> than in CDO.
> I have more comments in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366
>
> Cheers
> /Eike
>
>
--------------090606060501000402050104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
.... another reason why I don't bellive that missing sync on the maps is
not the cause for the deadlocks is the following:<br>
I believe that in general too few sync *can* cause problems like data
corruption and subsequent failure but deadlock is more likely to occur
with too much or wrong sync.<br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
Eike Stepper schrieb:
<blockquote cite="mid:fb5kgk$sri$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Simon McDuff schrieb:
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.6000.16525" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">All the following operations <font
face="Arial" size="2">are not thread safe.. Right?</font></font></div>
</blockquote>
The operations (assignment of HashMap) are thread safe because they
happen during construction time of their containing instance.<br>
I guess you mean that subsequent operations on the maps are not thread
safe?<br>
.....<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDORevisionResolverImpl</font></div>
<div><font face="Arial" size="2">private Map<CDOID, TimeLine>
revisions = new HashMap();</font></div>
</blockquote>
First I thought this one is thread safe because it is protected by the
internal semantics of ITransaction.<br>
A CDORevision itself is immutable once created so there's no danger.<br>
But now I'm not sure if it could come to problems due to the internal
mechanics of HashMap.<br>
Maybe it'd be better to use a ConcurrentHashMap for <font face="Arial"
size="2">CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue
as super class of TimeLine</font>.<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDOViewImpl </font></div>
<div><font face="Arial" size="2">private Map<CDOID,
InternalCDOObject> objects = new HashMap();</font></div>
</blockquote>
A CDOView is not thread safe by definition.<br>
It shall only be used by a single thread because it contains a
ResourceSet with Resources with EObjects and EObjects are not thread
safe by default (Ed?).<br>
Even EModelElements are only read-only thread safe
(<a moz-do-not-send="true" class="moz-txt-link-freetext"
href=" http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html"> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html</a>).<br>
<br>
Basically I believe that the root cause is somewhere in Net4j rather
than in CDO.<br>
I have more comments in
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366">https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366</a><br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
</blockquote>
</body>
</html>
--------------090606060501000402050104--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO][0.8.0] Thread Safe - hanging problems [message #609586 is a reply to message #94920] |
Thu, 30 August 2007 11:57 |
Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020604010706030100090106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Eike,
One example I often give when people ask about thread safety is to
consider the following code applied to a thread safe list.
int index = list.indexOf(x);
list.remove(index);
Even though the list might well be thread safe, this code isn't. So
generally, even if everything you use is thread safe, that doesn't mean
your higher level algorithms will be thread safe. Any code that changes
the state of a complex model will require higher level concurrency control.
I often tell people to consider as well what would happen if we put
synchronized on every method. Not only wouldn't that solve all life's
threading problems, it would in fact be more than likely to cause new
ones, i.e., deadlock.
So all that pontificating aside, EMF models are generally read-only
thread safe, but since demand loading of proxies effectively changes the
state of a model, even things you think involve read only access might
well do more. Ecore itself is designed to be read-only thread safe.
And of course the above aren't a reason to throw up your hands. There
are definitely places where you will need to ensure that something is
done safely because the method being called really is intended to
support more than one thread calling it at once.
Eike Stepper wrote:
> Simon McDuff schrieb:
>> All the following operations are not thread safe.. Right?
> The operations (assignment of HashMap) are thread safe because they
> happen during construction time of their containing instance.
> I guess you mean that subsequent operations on the maps are not thread
> safe?
> ...
>
>> CDORevisionResolverImpl
>> private Map<CDOID, TimeLine> revisions = new HashMap();
> First I thought this one is thread safe because it is protected by the
> internal semantics of ITransaction.
> A CDORevision itself is immutable once created so there's no danger.
> But now I'm not sure if it could come to problems due to the internal
> mechanics of HashMap.
> Maybe it'd be better to use a ConcurrentHashMap for
> CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue as super
> class of TimeLine.
>
>> CDOViewImpl
>> private Map<CDOID, InternalCDOObject> objects = new HashMap();
> A CDOView is not thread safe by definition.
> It shall only be used by a single thread because it contains a
> ResourceSet with Resources with EObjects and EObjects are not thread
> safe by default (Ed?).
> Even EModelElements are only read-only thread safe
> ( http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html).
>
> Basically I believe that the root cause is somewhere in Net4j rather
> than in CDO.
> I have more comments in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366
>
> Cheers
> /Eike
>
>
--------------020604010706030100090106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Eike,<br>
<br>
One example I often give when people ask about thread safety is to
consider the following code applied to a thread safe list.<br>
<blockquote>int index = list.indexOf(x);<br>
list.remove(index);<br>
</blockquote>
Even though the list might well be thread safe, this code isn't. So
generally, even if everything you use is thread safe, that doesn't mean
your higher level algorithms will be thread safe. Any code that
changes the state of a complex model will require higher level
concurrency control.<br>
<br>
I often tell people to consider as well what would happen if we put
synchronized on every method. Not only wouldn't that solve all life's
threading problems, it would in fact be more than likely to cause new
ones, i.e., deadlock.<br>
<br>
So all that pontificating aside, EMF models are generally read-only
thread safe, but since demand loading of proxies effectively changes
the state of a model, even things you think involve read only access
might well do more. Ecore itself is designed to be read-only thread
safe. And of course the above aren't a reason to throw up your hands.
There are definitely places where you will need to ensure that
something is done safely because the method being called really is
intended to support more than one thread calling it at once.<br>
<br>
<br>
Eike Stepper wrote:
<blockquote cite="mid:fb5kgk$sri$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Simon McDuff schrieb:
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.6000.16525" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">All the following operations <font
face="Arial" size="2">are not thread safe.. Right?</font></font></div>
</blockquote>
The operations (assignment of HashMap) are thread safe because they
happen during construction time of their containing instance.<br>
I guess you mean that subsequent operations on the maps are not thread
safe?<br>
....<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDORevisionResolverImpl</font></div>
<div><font face="Arial" size="2">private Map<CDOID, TimeLine>
revisions = new HashMap();</font></div>
</blockquote>
First I thought this one is thread safe because it is protected by the
internal semantics of ITransaction.<br>
A CDORevision itself is immutable once created so there's no danger.<br>
But now I'm not sure if it could come to problems due to the internal
mechanics of HashMap.<br>
Maybe it'd be better to use a ConcurrentHashMap for <font face="Arial"
size="2">CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue
as super class of TimeLine</font>.<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDOViewImpl </font></div>
<div><font face="Arial" size="2">private Map<CDOID,
InternalCDOObject> objects = new HashMap();</font></div>
</blockquote>
A CDOView is not thread safe by definition.<br>
It shall only be used by a single thread because it contains a
ResourceSet with Resources with EObjects and EObjects are not thread
safe by default (Ed?).<br>
Even EModelElements are only read-only thread safe
(<a moz-do-not-send="true" class="moz-txt-link-freetext"
href=" http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html"> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html</a>).<br>
<br>
Basically I believe that the root cause is somewhere in Net4j rather
than in CDO.<br>
I have more comments in
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366">https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366</a><br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>
--------------020604010706030100090106--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [CDO][0.8.0] Thread Safe - hanging problems [message #609588 is a reply to message #94979] |
Thu, 30 August 2007 12:13 |
|
This is a multi-part message in MIME format.
--------------080905090106060702000003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Ed,
It's clear to me that I have to protect subsequent accesses to a thread
safe data structure, for example:
synchronized (revisions)
{
TimeLine timeLine = revisions.get(id);
if (timeLine == null)
{
timeLine = new TimeLine(id);
revisions.put(id, timeLine);
}
return timeLine;
}
But if the used data structure is not thread safe in itself two threads
could mess it up with a single access each.
A HashMap.put() for example could cause rehashing while another thread
is trying to access the map.
Cheers
/Eike
Ed Merks schrieb:
> Eike,
>
> One example I often give when people ask about thread safety is to
> consider the following code applied to a thread safe list.
>
> int index = list.indexOf(x);
> list.remove(index);
>
> Even though the list might well be thread safe, this code isn't. So
> generally, even if everything you use is thread safe, that doesn't
> mean your higher level algorithms will be thread safe. Any code that
> changes the state of a complex model will require higher level
> concurrency control.
>
> I often tell people to consider as well what would happen if we put
> synchronized on every method. Not only wouldn't that solve all life's
> threading problems, it would in fact be more than likely to cause new
> ones, i.e., deadlock.
>
> So all that pontificating aside, EMF models are generally read-only
> thread safe, but since demand loading of proxies effectively changes
> the state of a model, even things you think involve read only access
> might well do more. Ecore itself is designed to be read-only thread
> safe. And of course the above aren't a reason to throw up your
> hands. There are definitely places where you will need to ensure that
> something is done safely because the method being called really is
> intended to support more than one thread calling it at once.
>
>
> Eike Stepper wrote:
>> Simon McDuff schrieb:
>>> All the following operations are not thread safe.. Right?
>> The operations (assignment of HashMap) are thread safe because they
>> happen during construction time of their containing instance.
>> I guess you mean that subsequent operations on the maps are not
>> thread safe?
>> ....
>>
>>> CDORevisionResolverImpl
>>> private Map<CDOID, TimeLine> revisions = new HashMap();
>> First I thought this one is thread safe because it is protected by
>> the internal semantics of ITransaction.
>> A CDORevision itself is immutable once created so there's no danger.
>> But now I'm not sure if it could come to problems due to the internal
>> mechanics of HashMap.
>> Maybe it'd be better to use a ConcurrentHashMap for
>> CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue as
>> super class of TimeLine.
>>
>>> CDOViewImpl
>>> private Map<CDOID, InternalCDOObject> objects = new HashMap();
>> A CDOView is not thread safe by definition.
>> It shall only be used by a single thread because it contains a
>> ResourceSet with Resources with EObjects and EObjects are not thread
>> safe by default (Ed?).
>> Even EModelElements are only read-only thread safe
>> ( http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html).
>>
>> Basically I believe that the root cause is somewhere in Net4j rather
>> than in CDO.
>> I have more comments in
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366
>>
>> Cheers
>> /Eike
>>
>>
>
--------------080905090106060702000003
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ed,<br>
<br>
It's clear to me that I have to protect subsequent accesses to a thread
safe data structure, for example:<br>
<br>
synchronized (revisions)<br>
{<br>
TimeLine timeLine = revisions.get(id);<br>
if (timeLine == null)<br>
{<br>
timeLine = new TimeLine(id);<br>
revisions.put(id, timeLine);<br>
}<br>
<br>
return timeLine;<br>
}<br>
<br>
But if the used data structure is not thread safe in itself two threads
could mess it up with a single access each.<br>
A HashMap.put() for example could cause rehashing while another thread
is trying to access the map.<br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
Ed Merks schrieb:
<blockquote cite="mid:fb6b7f$n49$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Eike,<br>
<br>
One example I often give when people ask about thread safety is to
consider the following code applied to a thread safe list.<br>
<blockquote>int index = list.indexOf(x);<br>
list.remove(index);<br>
</blockquote>
Even though the list might well be thread safe, this code isn't. So
generally, even if everything you use is thread safe, that doesn't mean
your higher level algorithms will be thread safe. Any code that
changes the state of a complex model will require higher level
concurrency control.<br>
<br>
I often tell people to consider as well what would happen if we put
synchronized on every method. Not only wouldn't that solve all life's
threading problems, it would in fact be more than likely to cause new
ones, i.e., deadlock.<br>
<br>
So all that pontificating aside, EMF models are generally read-only
thread safe, but since demand loading of proxies effectively changes
the state of a model, even things you think involve read only access
might well do more. Ecore itself is designed to be read-only thread
safe. And of course the above aren't a reason to throw up your hands.
There are definitely places where you will need to ensure that
something is done safely because the method being called really is
intended to support more than one thread calling it at once.<br>
<br>
<br>
Eike Stepper wrote:
<blockquote cite="mid:fb5kgk$sri$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
Simon McDuff schrieb:
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.6000.16525" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">All the following operations <font
face="Arial" size="2">are not thread safe.. Right?</font></font></div>
</blockquote>
The operations (assignment of HashMap) are thread safe because they
happen during construction time of their containing instance.<br>
I guess you mean that subsequent operations on the maps are not thread
safe?<br>
.....<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDORevisionResolverImpl</font></div>
<div><font face="Arial" size="2">private Map<CDOID,
TimeLine>
revisions = new HashMap();</font></div>
</blockquote>
First I thought this one is thread safe because it is protected by the
internal semantics of ITransaction.<br>
A CDORevision itself is immutable once created so there's no danger.<br>
But now I'm not sure if it could come to problems due to the internal
mechanics of HashMap.<br>
Maybe it'd be better to use a ConcurrentHashMap for <font face="Arial"
size="2">CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue
as super class of TimeLine</font>.<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDOViewImpl </font></div>
<div><font face="Arial" size="2">private Map<CDOID,
InternalCDOObject> objects = new HashMap();</font></div>
</blockquote>
A CDOView is not thread safe by definition.<br>
It shall only be used by a single thread because it contains a
ResourceSet with Resources with EObjects and EObjects are not thread
safe by default (Ed?).<br>
Even EModelElements are only read-only thread safe
(<a moz-do-not-send="true" class="moz-txt-link-freetext"
href=" http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html"> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html</a>).<br>
<br>
Basically I believe that the root cause is somewhere in Net4j rather
than in CDO.<br>
I have more comments in <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366">https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366</a><br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
</body>
</html>
--------------080905090106060702000003--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO][0.8.0] Thread Safe - hanging problems [message #609589 is a reply to message #94964] |
Thu, 30 August 2007 12:14 |
|
This is a multi-part message in MIME format.
--------------080608000109070005090109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I've added chained synchronization to CDORevisionResolverImpl.
What do you think?
Simon McDuff schrieb:
> Sorry Eike, I wasn't clear enough.. but I thought it was obvious.
>
> Everyone that connect to that repository will go through these
> variable and call
>
>
> TimeLine timeLine = revisions.get(id);
>
> *if* (timeLine == *null*)
>
> {
>
> timeLine = *new* TimeLine(id);
>
> revisions.put(id, timeLine);
>
> }
>
> *return* timeLine;
>
>
>
> We could have a problem there.... everywhere where we use revisions...
> not when we contruct it.
>
> Same thing for other attributs I mention...
>
>
>
>
>
>
> "Eike Stepper" <stepper@sympedia.de <mailto:stepper@sympedia.de>>
> wrote in message news:fb5kgk$sri$1@build.eclipse.org...
> Simon McDuff schrieb:
>> All the following operations are not thread safe.. Right?
> The operations (assignment of HashMap) are thread safe because
> they happen during construction time of their containing instance.
> I guess you mean that subsequent operations on the maps are not
> thread safe?
> ...
>
>> CDORevisionResolverImpl
>> private Map<CDOID, TimeLine> revisions = new HashMap();
> First I thought this one is thread safe because it is protected by
> the internal semantics of ITransaction.
> A CDORevision itself is immutable once created so there's no danger.
> But now I'm not sure if it could come to problems due to the
> internal mechanics of HashMap.
> Maybe it'd be better to use a ConcurrentHashMap for
> CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue as
> super class of TimeLine.
>
>> CDOViewImpl
>> private Map<CDOID, InternalCDOObject> objects = new HashMap();
> A CDOView is not thread safe by definition.
> It shall only be used by a single thread because it contains a
> ResourceSet with Resources with EObjects and EObjects are not
> thread safe by default (Ed?).
> Even EModelElements are only read-only thread safe
> ( http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html).
>
> Basically I believe that the root cause is somewhere in Net4j
> rather than in CDO.
> I have more comments in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366
>
> Cheers
> /Eike
>
>
--------------080608000109070005090109
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I've added chained synchronization to CDORevisionResolverImpl.<br>
What do you think?<br>
<br>
<br>
Simon McDuff schrieb:
<blockquote cite="mid:fb68qk$f43$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<meta content="MSHTML 6.00.2900.3157" name="GENERATOR">
<div><font face="Arial" size="2">Sorry Eike, I wasn't clear enough..
but I thought it was obvious.</font></div>
<div> </div>
<div><font face="Arial" size="2">Everyone that connect to that
repository will go through these variable and call</font></div>
<div> </div>
<div><font size="2">
</font>
<p align="left"><font size="2">TimeLine timeLine = </font><font
color="#0000c0" size="2">revisions</font><font size="2">.get(id);</font></p>
<p align="left"><b><font color="#7f0055" size="2">if</font></b><font
size="2"> (timeLine == </font><b><font color="#7f0055" size="2">null</font></b><font
size="2">)</font></p>
<p align="left"><font size="2">{</font></p>
<p align="left"><font size="2">timeLine = </font><b><font
color="#7f0055" size="2">new</font></b><font size="2"> TimeLine(id);</font></p>
<p align="left"><font color="#0000c0" size="2">revisions</font><font
size="2">.put(id, timeLine);</font></p>
<p align="left"><font size="2">}</font></p>
<p align="left"><b><font color="#7f0055" size="2">return</font></b><font
size="2"> timeLine;</font></p>
<p align="left"> </p>
<p align="left"><font size="2">We could have a problem there....
everywhere where we use <font color="#0000c0">revisions... not when we
contruct it.</font></font></p>
<p align="left"><font size="2"><font face="Arial">Same thing for
other attributs I mention... </font></font></p>
<p align="left"><font size="2"> </font></p>
</div>
<div> </div>
<div> </div>
<blockquote
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div>"Eike Stepper" <<a moz-do-not-send="true"
href="mailto:stepper@sympedia.de">stepper@sympedia.de</a>> wrote in
message <a moz-do-not-send="true"
href="news:fb5kgk$sri$1@build.eclipse.org">news:fb5kgk$sri$1@build.eclipse.org</a>...</div>
Simon McDuff schrieb:
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<meta content="MSHTML 6.00.6000.16525" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">All the following operations <font
face="Arial" size="2">are not thread safe.. Right?</font></font></div>
</blockquote>
The operations (assignment of HashMap) are thread safe because they
happen during construction time of their containing instance.<br>
I guess you mean that subsequent operations on the maps are not thread
safe?<br>
....<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDORevisionResolverImpl</font></div>
<div><font face="Arial" size="2">private Map<CDOID,
TimeLine> revisions = new HashMap();</font></div>
</blockquote>
First I thought this one is thread safe because it is protected by the
internal semantics of ITransaction.<br>
A CDORevision itself is immutable once created so there's no danger.<br>
But now I'm not sure if it could come to problems due to the internal
mechanics of HashMap.<br>
Maybe it'd be better to use a ConcurrentHashMap for <font face="Arial"
size="2">CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue
as super class of TimeLine</font>.<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDOViewImpl </font></div>
<div><font face="Arial" size="2">private Map<CDOID,
InternalCDOObject> objects = new HashMap();</font></div>
</blockquote>
A CDOView is not thread safe by definition.<br>
It shall only be used by a single thread because it contains a
ResourceSet with Resources with EObjects and EObjects are not thread
safe by default (Ed?).<br>
Even EModelElements are only read-only thread safe (<a
moz-do-not-send="true" class="moz-txt-link-freetext"
href=" http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html"> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html</a>).<br>
<br>
Basically I believe that the root cause is somewhere in Net4j rather
than in CDO.<br>
I have more comments in <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366">https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366</a><br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
</blockquote>
</blockquote>
</body>
</html>
--------------080608000109070005090109--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO][0.8.0] Thread Safe - hanging problems [message #609590 is a reply to message #95025] |
Thu, 30 August 2007 12:32 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0311_01C7EAE0.564C3FC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
This seems to be well done. But I'm not an expert :-)
It is working with my JCSMap as well !!!!
"Eike Stepper" <stepper@sympedia.de> wrote in message =
news:fb6cak$sri$4@build.eclipse.org...
I've added chained synchronization to CDORevisionResolverImpl.
What do you think?
Simon McDuff schrieb:=20
Sorry Eike, I wasn't clear enough.. but I thought it was obvious.
Everyone that connect to that repository will go through these =
variable and call
TimeLine timeLine =3D revisions.get(id);
if (timeLine =3D=3D null)
{
timeLine =3D new TimeLine(id);
revisions.put(id, timeLine);
}
return timeLine;
We could have a problem there.... everywhere where we use =
revisions... not when we contruct it.
Same thing for other attributs I mention...=20
"Eike Stepper" <stepper@sympedia.de> wrote in message =
news:fb5kgk$sri$1@build.eclipse.org...
Simon McDuff schrieb:=20
All the following operations are not thread safe.. Right?
The operations (assignment of HashMap) are thread safe because =
they happen during construction time of their containing instance.
I guess you mean that subsequent operations on the maps are not =
thread safe?
...
CDORevisionResolverImpl
private Map<CDOID, TimeLine> revisions =3D new HashMap();
First I thought this one is thread safe because it is protected by =
the internal semantics of ITransaction.
A CDORevision itself is immutable once created so there's no =
danger.
But now I'm not sure if it could come to problems due to the =
internal mechanics of HashMap.
Maybe it'd be better to use a ConcurrentHashMap for =
CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue as super =
class of TimeLine.
CDOViewImpl=20
private Map<CDOID, InternalCDOObject> objects =3D new HashMap();
A CDOView is not thread safe by definition.
It shall only be used by a single thread because it contains a =
ResourceSet with Resources with EObjects and EObjects are not thread =
safe by default (Ed?).
Even EModelElements are only read-only thread safe =
( http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html).
Basically I believe that the root cause is somewhere in Net4j =
rather than in CDO.
I have more comments in =
https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D201366
Cheers
/Eike
------=_NextPart_000_0311_01C7EAE0.564C3FC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>This seems to be well done. But I'm not =
an expert=20
:-)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>It is working with my JCSMap as well=20
!!!!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>"Eike Stepper" <<A=20
href=3D"mailto:stepper@sympedia.de">stepper@sympedia.de</A>> wrote in =
message=20
<A=20
href=3D"news:fb6cak$sri$4@build.eclipse.org">news:fb6cak$sri$4@build.ecli=
pse.org</A>...</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">I've=20
added chained synchronization to CDORevisionResolverImpl.<BR>What do =
you=20
think?<BR><BR><BR>Simon McDuff schrieb:=20
<BLOCKQUOTE cite=3Dmid:fb68qk$f43$1@build.eclipse.org type=3D"cite">
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR>
<DIV><FONT face=3DArial size=3D2>Sorry Eike, I wasn't clear enough.. =
but I=20
thought it was obvious.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Everyone that connect to that =
repository will=20
go through these variable and call</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2></FONT>
<P align=3Dleft><FONT size=3D2>TimeLine timeLine =3D </FONT><FONT =
color=3D#0000c0=20
size=3D2>revisions</FONT><FONT size=3D2>.get(id);</FONT></P>
<P align=3Dleft><B><FONT color=3D#7f0055 size=3D2>if</FONT></B><FONT =
size=3D2>=20
(timeLine =3D=3D </FONT><B><FONT color=3D#7f0055 =
size=3D2>null</FONT></B><FONT=20
size=3D2>)</FONT></P>
<P align=3Dleft><FONT size=3D2>{</FONT></P>
<P align=3Dleft><FONT size=3D2>timeLine =3D </FONT><B><FONT =
color=3D#7f0055=20
size=3D2>new</FONT></B><FONT size=3D2> TimeLine(id);</FONT></P>
<P align=3Dleft><FONT color=3D#0000c0 size=3D2>revisions</FONT><FONT =
size=3D2>.put(id, timeLine);</FONT></P>
<P align=3Dleft><FONT size=3D2>}</FONT></P>
<P align=3Dleft><B><FONT color=3D#7f0055 =
size=3D2>return</FONT></B><FONT size=3D2>=20
timeLine;</FONT></P>
<P align=3Dleft> </P>
<P align=3Dleft><FONT size=3D2>We could have a problem there.... =
everywhere=20
where we use <FONT color=3D#0000c0>revisions... not when we contruct =
it.</FONT></FONT></P>
<P align=3Dleft><FONT size=3D2><FONT face=3DArial>Same thing for =
other attributs I=20
mention... </FONT></FONT></P>
<P align=3Dleft><FONT size=3D2></FONT> </P></DIV>
<DIV> </DIV>
<DIV> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: rgb(0,0,0) 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Eike Stepper" <<A href=3D"mailto:stepper@sympedia.de"=20
moz-do-not-send=3D"true">stepper@sympedia.de</A>> wrote in =
message <A=20
href=3D"news:fb5kgk$sri$1@build.eclipse.org"=20
=
moz-do-not-send=3D"true">news:fb5kgk$sri$1@build.eclipse.org</A>...</DIV>=
Simon=20
McDuff schrieb:=20
<BLOCKQUOTE cite=3Dmid:fb542f$90d$1@build.eclipse.org =
type=3D"cite">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
<DIV><FONT face=3DArial size=3D2>All the following =
operations <FONT=20
face=3DArial size=3D2>are not thread safe..=20
Right?</FONT></FONT></DIV></BLOCKQUOTE>The operations (assignment =
of=20
HashMap) are thread safe because they happen during construction =
time of=20
their containing instance.<BR>I guess you mean that subsequent =
operations=20
on the maps are not thread safe?<BR>...<BR><BR>
<BLOCKQUOTE cite=3Dmid:fb542f$90d$1@build.eclipse.org =
type=3D"cite">
<DIV><FONT face=3DArial =
size=3D2>CDORevisionResolverImpl</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>private Map<CDOID, =
TimeLine>=20
revisions =3D new HashMap();</FONT></DIV></BLOCKQUOTE>First I =
thought this=20
one is thread safe because it is protected by the internal =
semantics of=20
ITransaction.<BR>A CDORevision itself is immutable once created so =
there's=20
no danger.<BR>But now I'm not sure if it could come to problems =
due to the=20
internal mechanics of HashMap.<BR>Maybe it'd be better to use a=20
ConcurrentHashMap for <FONT face=3DArial=20
size=3D2>CDORevisionResolverImpl.revisions and a =
ConcurrentLinkedQueue as=20
super class of TimeLine</FONT>.<BR><BR>
<BLOCKQUOTE cite=3Dmid:fb542f$90d$1@build.eclipse.org =
type=3D"cite">
<DIV><FONT face=3DArial size=3D2>CDOViewImpl </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>private Map<CDOID, =
InternalCDOObject>=20
objects =3D new HashMap();</FONT></DIV></BLOCKQUOTE>A CDOView is =
not thread=20
safe by definition.<BR>It shall only be used by a single thread =
because it=20
contains a ResourceSet with Resources with EObjects and EObjects =
are not=20
thread safe by default (Ed?).<BR>Even EModelElements are only =
read-only=20
thread safe (<A class=3Dmoz-txt-link-freetext=20
=
href=3D" http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.=
html"=20
=
moz-do-not-send=3D"true">http://dev.eclipse.org/newslists/news.eclipse.to=
ols.emf/msg26143.html</A>).<BR><BR>Basically=20
I believe that the root cause is somewhere in Net4j rather than in =
CDO.<BR>I have more comments in <A class=3Dmoz-txt-link-freetext=20
href=3D"https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D201366"=20
=
moz-do-not-send=3D"true">https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D=
201366</A><BR><BR>Cheers<BR>/Eike<BR><BR><BR></BLOCKQUOTE ></BLOCKQUOTE></=
BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0311_01C7EAE0.564C3FC0--
|
|
|
| Re: [CDO][0.8.0] Thread Safe - hanging problems [message #609591 is a reply to message #95012] |
Thu, 30 August 2007 14:35 |
Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000807020602010305060601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Eike,
Yes, this is definitely a case where you need to synchronize properly.
Eike Stepper wrote:
> Ed,
>
> It's clear to me that I have to protect subsequent accesses to a
> thread safe data structure, for example:
>
> synchronized (revisions)
> {
> TimeLine timeLine = revisions.get(id);
> if (timeLine == null)
> {
> timeLine = new TimeLine(id);
> revisions.put(id, timeLine);
> }
>
> return timeLine;
> }
>
> But if the used data structure is not thread safe in itself two
> threads could mess it up with a single access each.
> A HashMap.put() for example could cause rehashing while another thread
> is trying to access the map.
>
> Cheers
> /Eike
>
>
> Ed Merks schrieb:
>> Eike,
>>
>> One example I often give when people ask about thread safety is to
>> consider the following code applied to a thread safe list.
>>
>> int index = list.indexOf(x);
>> list.remove(index);
>>
>> Even though the list might well be thread safe, this code isn't. So
>> generally, even if everything you use is thread safe, that doesn't
>> mean your higher level algorithms will be thread safe. Any code that
>> changes the state of a complex model will require higher level
>> concurrency control.
>>
>> I often tell people to consider as well what would happen if we put
>> synchronized on every method. Not only wouldn't that solve all
>> life's threading problems, it would in fact be more than likely to
>> cause new ones, i.e., deadlock.
>>
>> So all that pontificating aside, EMF models are generally read-only
>> thread safe, but since demand loading of proxies effectively changes
>> the state of a model, even things you think involve read only access
>> might well do more. Ecore itself is designed to be read-only thread
>> safe. And of course the above aren't a reason to throw up your
>> hands. There are definitely places where you will need to ensure
>> that something is done safely because the method being called really
>> is intended to support more than one thread calling it at once.
>>
>>
>> Eike Stepper wrote:
>>> Simon McDuff schrieb:
>>>> All the following operations are not thread safe.. Right?
>>> The operations (assignment of HashMap) are thread safe because they
>>> happen during construction time of their containing instance.
>>> I guess you mean that subsequent operations on the maps are not
>>> thread safe?
>>> ....
>>>
>>>> CDORevisionResolverImpl
>>>> private Map<CDOID, TimeLine> revisions = new HashMap();
>>> First I thought this one is thread safe because it is protected by
>>> the internal semantics of ITransaction.
>>> A CDORevision itself is immutable once created so there's no danger.
>>> But now I'm not sure if it could come to problems due to the
>>> internal mechanics of HashMap.
>>> Maybe it'd be better to use a ConcurrentHashMap for
>>> CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue as
>>> super class of TimeLine.
>>>
>>>> CDOViewImpl
>>>> private Map<CDOID, InternalCDOObject> objects = new HashMap();
>>> A CDOView is not thread safe by definition.
>>> It shall only be used by a single thread because it contains a
>>> ResourceSet with Resources with EObjects and EObjects are not thread
>>> safe by default (Ed?).
>>> Even EModelElements are only read-only thread safe
>>> ( http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html).
>>>
>>> Basically I believe that the root cause is somewhere in Net4j rather
>>> than in CDO.
>>> I have more comments in
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>
--------------000807020602010305060601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Eike,<br>
<br>
Yes, this is definitely a case where you need to synchronize properly.<br>
<br>
<br>
Eike Stepper wrote:
<blockquote cite="mid:fb6c86$sri$3@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Ed,<br>
<br>
It's clear to me that I have to protect subsequent accesses to a thread
safe data structure, for example:<br>
<br>
synchronized (revisions)<br>
{<br>
TimeLine timeLine = revisions.get(id);<br>
if (timeLine == null)<br>
{<br>
timeLine = new TimeLine(id);<br>
revisions.put(id, timeLine);<br>
}<br>
<br>
return timeLine;<br>
}<br>
<br>
But if the used data structure is not thread safe in itself two threads
could mess it up with a single access each.<br>
A HashMap.put() for example could cause rehashing while another thread
is trying to access the map.<br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
Ed Merks schrieb:
<blockquote cite="mid:fb6b7f$n49$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
Eike,<br>
<br>
One example I often give when people ask about thread safety is to
consider the following code applied to a thread safe list.<br>
<blockquote>int index = list.indexOf(x);<br>
list.remove(index);<br>
</blockquote>
Even though the list might well be thread safe, this code isn't. So
generally, even if everything you use is thread safe, that doesn't mean
your higher level algorithms will be thread safe. Any code that
changes the state of a complex model will require higher level
concurrency control.<br>
<br>
I often tell people to consider as well what would happen if we put
synchronized on every method. Not only wouldn't that solve all life's
threading problems, it would in fact be more than likely to cause new
ones, i.e., deadlock.<br>
<br>
So all that pontificating aside, EMF models are generally read-only
thread safe, but since demand loading of proxies effectively changes
the state of a model, even things you think involve read only access
might well do more. Ecore itself is designed to be read-only thread
safe. And of course the above aren't a reason to throw up your hands.
There are definitely places where you will need to ensure that
something is done safely because the method being called really is
intended to support more than one thread calling it at once.<br>
<br>
<br>
Eike Stepper wrote:
<blockquote cite="mid:fb5kgk$sri$1@build.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
Simon McDuff schrieb:
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.6000.16525" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">All the following operations <font
face="Arial" size="2">are not thread safe.. Right?</font></font></div>
</blockquote>
The operations (assignment of HashMap) are thread safe because they
happen during construction time of their containing instance.<br>
I guess you mean that subsequent operations on the maps are not thread
safe?<br>
.....<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDORevisionResolverImpl</font></div>
<div><font face="Arial" size="2">private Map<CDOID,
TimeLine>
revisions = new HashMap();</font></div>
</blockquote>
First I thought this one is thread safe because it is protected by the
internal semantics of ITransaction.<br>
A CDORevision itself is immutable once created so there's no danger.<br>
But now I'm not sure if it could come to problems due to the internal
mechanics of HashMap.<br>
Maybe it'd be better to use a ConcurrentHashMap for <font face="Arial"
size="2">CDORevisionResolverImpl.revisions and a ConcurrentLinkedQueue
as super class of TimeLine</font>.<br>
<br>
<blockquote cite="mid:fb542f$90d$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2">CDOViewImpl </font></div>
<div><font face="Arial" size="2">private Map<CDOID,
InternalCDOObject> objects = new HashMap();</font></div>
</blockquote>
A CDOView is not thread safe by definition.<br>
It shall only be used by a single thread because it contains a
ResourceSet with Resources with EObjects and EObjects are not thread
safe by default (Ed?).<br>
Even EModelElements are only read-only thread safe
(<a moz-do-not-send="true" class="moz-txt-link-freetext"
href=" http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html"> http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg2 6143.html</a>).<br>
<br>
Basically I believe that the root cause is somewhere in Net4j rather
than in CDO.<br>
I have more comments in <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366">https://bugs.eclipse.org/bugs/show_bug.cgi?id=201366</a><br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------000807020602010305060601--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [CDO][0.8.0] Thread Safe - hanging problems [message #609592 is a reply to message #95040] |
Thu, 30 August 2007 14:49 |
|
This is a multi-part message in MIME format.
--------------050408050200070208000101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Simon McDuff schrieb:
> This seems to be well done. But I'm not an expert :-)
> It is working with my JCSMap as well !!!!
Cool!!! I'm happy that it's solved and sorry for the inconvenience.
Maybe in the future when we recognize that too many threads are being
allocated we are brave enough to give AsynchronousWorkSerializer another
try ;-)
BTW. I've added the following to Channel.doDeactivate()
if (receiveSerializer != null)
{
receiveSerializer.dispose();
receiveSerializer = null;
}
Cheers
/Eike
--------------050408050200070208000101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Simon McDuff schrieb:
<blockquote cite="mid:fb6ddd$i4i$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<meta content="MSHTML 6.00.2900.3157" name="GENERATOR">
<div><font face="Arial" size="2">This seems to be well done. But I'm
not an expert :-)</font></div>
<div><font face="Arial" size="2">It is working with my JCSMap as well
!!!!</font></div>
</blockquote>
Cool!!! I'm happy that it's solved and sorry for the inconvenience.<br>
Maybe in the future when we recognize that too many threads are being
allocated we are brave enough to give AsynchronousWorkSerializer
another try ;-)<br>
<br>
BTW. I've added the following to Channel.doDeactivate()<br>
<br>
if (receiveSerializer != null)<br>
{<br>
receiveSerializer.dispose();<br>
receiveSerializer = null;<br>
}<br>
<br>
Cheers<br>
/Eike<br>
<br>
</body>
</html>
--------------050408050200070208000101--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Fri Nov 08 21:49:23 GMT 2024
Powered by FUDForum. Page generated in 0.06031 seconds |
] 
Search
Help
Register
Login
Home
