Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Defect of threaded safe #35

Closed
GoogleCodeExporter opened this issue Jul 1, 2015 · 10 comments
Closed

Defect of threaded safe #35

GoogleCodeExporter opened this issue Jul 1, 2015 · 10 comments

Comments

@GoogleCodeExporter
Copy link

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
Copy link
Author

[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
Copy link
Author

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

  • Changed state: Started

@GoogleCodeExporter
Copy link
Author

I wait for to hear your good news.

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

@GoogleCodeExporter
Copy link
Author

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

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

(fixed in latest build)

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

@GoogleCodeExporter
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

Oh, I have tested again . You are right.

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

@GoogleCodeExporter
Copy link
Author

Closed (verified)

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

  • Changed state: Verified

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant