search

tonynhan / protobuf-net

Automatically exported from code.google.com/p/protobuf-net
Other
0 stars 0 forks source link

Defect of threaded safe #35

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
kiminozo.eien@gmail.com
==============

What steps will reproduce the problem?
1. My Program is running in multi-thread;
2. A haphazard occurrence. 
The value of member Serializer<T>.subclasses is null;
3.

What is the expected output? What do you see instead?
I think the "subclasses" is not threaded safe variables.
I think it must add a head "[ThreadStatic]";

What version of the product are you using? On what operating system?
1.0.0.213 win2008

Please provide any additional information below.

Original issue reported on code.google.com by kiminozo...@gmail.com on 9 Dec 2008 at 1:54

Attachments:

GoogleCodeExporter commented 9 years ago 
[ThreadStatic]
private static Property<T>[] readProps, writeProps;

[ThreadStatic]
 private static KeyValuePair<Type, Property<T, T>>[] subclasses;

Original comment by kiminozo...@gmail.com on 9 Dec 2008 at 2:04

GoogleCodeExporter commented 9 years ago 
OK, I will post a fix later today - but I don't think [ThreadStatic] will be 
the way, 
since that would preclude any re-use. It will be something related, though.

Original comment by marc.gravell on 9 Dec 2008 at 4:58

GoogleCodeExporter commented 9 years ago 
I wait for to hear your good news.

Original comment by kiminozo...@gmail.com on 9 Dec 2008 at 5:48

GoogleCodeExporter commented 9 years ago

Original comment by marc.gravell on 9 Dec 2008 at 8:35

GoogleCodeExporter commented 9 years ago 
(fixed in latest build)

Original comment by marc.gravell on 9 Dec 2008 at 10:19

GoogleCodeExporter commented 9 years ago 
Oh,I have seen the latest build;
I find there is a new object "lockToken" to lock the threaded-unsafe-process.
but I don't think the Monitor will be the way, 
the Monitor just make a multi-thread program to a one-thread program.
I think it is not highly active way.

Original comment by kiminozo...@gmail.com on 9 Dec 2008 at 12:42

GoogleCodeExporter commented 9 years ago 
No, that isn't what it does... the lock is *only* taken during the Build() 
step; and 
only if the model hasn't already been built. For most cases, this will mean 
only one 
use of lock per-type, and after that no locks at all.

This change does not serialize calls to the main serialization code.

Original comment by marc.gravell on 9 Dec 2008 at 1:39

GoogleCodeExporter commented 9 years ago 
Ah, that accounts for it!
I will try it again tomorrow.

Original comment by kiminozo...@gmail.com on 9 Dec 2008 at 2:15

GoogleCodeExporter commented 9 years ago 
Oh, I have tested again . You are right.

Original comment by kiminozo...@gmail.com on 10 Dec 2008 at 3:03

GoogleCodeExporter commented 9 years ago 
Closed (verified)

Original comment by marc.gravell on 6 Jan 2009 at 7:51